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ABSTRACT 


The Anti-Submarine Warfare (ASW) eommunity requires a fully operational 
Command, Control, Communications, Computers, and Intelligence (C4I) architecture to 
significantly reduce time from sensor detection to defensive weapons release. The 
United States Navy has established programs of record leveraging space, terrestrial, and 
maritime communications capabilities extending to fiscal year 2015. An ordered systems 
engineering process was performed to derive requirements and identify Joint ASW C4I 
Architecture strengths and weaknesses. This architecture is dependent upon the ASW 
community’s ability to leverage current and planned technologies impacting C4I areas 
including common operational tactical picture delivery, data transmission rate, time 
latency, and data fusion processes. Performance forecasts for identified alternatives were 
modeled and simulated based on a synthesized operational scenario using the EXTEND 
simulation tool, and life cycle cost estimates were produced for each alternative. Based 
on those outcomes, one of the several alternatives is recommended for implementation. 

In addition, it was discovered that programmed C4I capabilities lack an integrated 
fielding plan and do not properly align in FY2020. Furthermore, the ASW community 
must make process changes to enable cross-program manager collaboration supported by 
a single system architect to ensure robust architectures are fielded by 2020. 
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EXECUTIVE SUMMARY 


This capstone project design team directed its efforts at providing the ASW 
community well researched alternatives for obtaining and maintaining a robust Joint 
ASW Command, Control, Communications, Computers, and Intelligence (C41) Architecture 
enabling reduction of communication exchange time from sensor awareness to weapons 
on target in fiscal year (FY) 2020 and beyond. A tailored systems engineering 
development process was used to accomplish this task. It consisted of needs analysis, 
value system design, alternatives generation, modeling of alternatives, alternative 
scoring, and determination of the best alternative. 

Needs analysis included consideration of needs, desires, and wants of the 
stakeholders, an overview of an adversarial submarine threat, the functional Joint ASW 
C4I Architecture, future C4I contributing systems, and identification of an effective need 
statement. Stakeholders agreed upon the following effective need statement: Key ASW 
stakeholders require a new standardized joint ASW-specific C4I architecture for the 2020 
target time frame. The proposed Joint ASW C4I Architecture needs to use open 
standards, common waveforms, and a common data schema. It needs to be consistent 
with DoD policy and processes and be vertically integrated with other DoD C4I systems. 

Value system design consisted of value hierarchy and evaluation measures. This 
step was crucial to accurately refining system requirements based on the effective need. 

It permitted insight into conflicting stakeholder preferences, allowed documentation of 
stakeholders’ objectives, and aided in evaluating and ranking design alternatives. The top 
ranked functions identified in this process were Provide ASW Common Operational 
Tactical Picture, Fuse ASW Data, Interconnect Communication Nodes, and Enable Smart 
Pull and Push of ASW Information. Alternatives were generated after researching 
current programs of record, network topologies, and techniques and technologies to 
communicate with submarines. A FY2020 Joint ASW C4I Architecture Baseline was 
analyzed to discern functional gaps in existing and planned C4I supporting system 
designs which led to the four feasible alternatives. 

The next step, alternatives generation, required significant research regarding 
programs of record planned changes, network topologies, and techniques to communicate 
with submarines. The four feasible alternative solutions consisted of Alternative 0 
(Baseline Architecture); Alternative 1 (Baseline Architecture plus Joint Tactical Radio 
System (JTRS) Increment 4, Net-Enabled Command Capability (NECC), and 
Consolidated Afloat Network Enterprise Services (CANES) improvements); Alternative 
2 (Baseline Architecture plus JTRS Increment 5, CANES improvements, and Joint Track 
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Manager); and Alternative 3 (Baseline Arehiteeture plus modulated x-ray souree 
eommunications system, autonomous Command, Control, Communications, Computers, 
Intelligence, Surveillance, and Recormaissance (C4ISR) Unmarmed Undersea Vehicles 
(UUVs), military High Altitude Aircraft (HAA), use of High Altitude Long Operation 
(HALO), Helios, and HAA for tropospheric or space-based distribution and ftrsion of 
common operational and tactical picture (COTP)). 

Each of the four alternatives were simulated in EXTEND. To simplify the 
simulation a static model of the FY2020 Joint ASW C41 Architecture Baseline was 
created using operational scenario-based communication transmissions. The evaluation 
measures obtained using multiple simulation runs were throughput, latency, and data 
fusion time. The results of the simulation were used in alternative performance scoring 
where Alternative 2 had the greatest throughput and Alternative 3 had the lowest latency 
value and lowest data fusion processing time. 

Life cycle cost estimates were developed for each alternative. The life cycle cost 
analysis considered all future costs associated with the Joint ASW C4I Architecture 
alternatives. It involved costs of all technical and management activities, research and 
development, production, operations and support, and disposal, throughout its lifetime 
and provided the basis for comparing alternatives. The cost model was developed using 
Microsoft Excel and calculated the cost of each task, life cycle phase, and year. Several 
cost estimation methods were used, including examining actual data from similar 
projects. 

The analysis of alternatives (AoA) provided the consolidation of alternative 
performance scoring and a methodology for determining the best alternative 
recommendation. Classic multi-attribute utility theory (MAUT) was used with adequate 
stakeholder feedback to complete the analysis of alternatives. Using cost as an 
independent variable, the AoA compared the alternatives’ ability to satisfy performance 
requirements to their life cycle cost to produce a cost-effectiveness comparison. 

Based on this comparison, it was clear that Alternative 3 could be discarded since 
it has a lower utility than Alternative 2 and costs more than seven times as much. 

Though the Baseline Architecture is consistent for all alternatives it is imperative that the 
ASW Community avoid high research and development costs for x-ray communications, 
autonomous C4ISR unmanned undersea vehicles (UUV), High Altitude Long Operation 
(HALO), Helios, and military High Altitude Airship (HAA) support platforms. It is 
advised that these future C4ISR opportunities be leveraged from a distance using results 
from other DoD agencies to gain insight into their utility. 
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In the end, Alternative 2 was recommended for further development. Alternative 
2 provides significant improvements in utility for a small cost. Further investigation and 
validation of Alternative 2 is recommended in a real world event. Further, it is 
recommended that the ASW community continue to support and fund all C4I related 
programs contributing to the FY2020 Baseline Architecture ensuring robust 
communications are fielded and sustained for all ASW platforms. 

During alternatives generation, it was discovered that there were many existing 
programs of record that collectively had capabilities that could fulfill the requirements 
and functionality identified for the Joint ASW C4I Architecture. So the focus was shifted 
to identifying a system of systems ASW C4I architecture to integrate and field the 
capabilities by fiscal year 2020. This required significant additional research regarding 
the selected program of record change plans because there was no top-down plan for 
integrating the individual systems into a Joint ASW C4I Architecture for a fiscal year 
2020 fielding. 

It is recommended that a full-time funded organization be stood up that manages 
from the system of systems level. This organization would enable program managers for 
the individual program of record systems that solve a piece of the C4I architecture to 
collaborate with other program managers of the individual programs of record that solve 
another piece. This will ensure proper integration. Further, this organization would 
provide the top-down program management and technical analysis required to effectively 
develop and implement a robust Joint ASW C4I Architecture. 
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I. INTRODUCTION 


A. PROBLEM STATEMENT 

The United States Navy’s conduct of anti-submarine warfare (ASW) today uses 
platform-centric ASW Command, Control, Communications, Computers, and 
Intelligence (C4I) systems that are not used in a networked fashion. Many were 
developed to support blue-water ASW operations and were designed in large part with 
communication architectures where data sharing may have been point-to-point and 
hierarchical rather than many-to-many and edge-oriented. They lack robust routing and 
networking capabilities, provide low to medium data throughput, and present logistics 
challenges. More specifically, the Navy has not employed the tenets and principles of 
network-centric warfare for ASW C4I systems which are displayed in Figure 1 [Miller, 
G., 2006]: 



Improves^ 



— Enhances^- 



Enables 


Enhances 



Figure 1. Tenets and Principles of Network Centric Warfare 

This is the logic path for the tenets and principles of network centric warfare. It shows how each 
capability is dependent on the previous capability and, in a sense, provided the priority from left to 
right. 


The threat today from quiet diesel-electrie and air-independent propulsion 
submarines operating in a littoral environment requires the ability to eonnect sensors and 
platforms in order to exehange data and share information. Without information sharing 
there can be a depletion of sensor or weapon resourees when needed most due to high 
false alarm rates, ineffective wide area seareh plans, and battle group asset dispersion 
[Clarkson, 2008]. Sharing of information requires ASW to be eondueted as a team. 
Commander Perry D. Yaw, United States Navy, diseussed the importance of teamwork in 
conducting ASW [Yaw, 2006]: 

ASW will remain a challenging mission area. It is, and will remain, a team sport 
for the Navy. Inereased complexity of the operating environment, an increasingly 
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capable threat, and limited depth on the Navy’s beneh require more inter-service 
cooperation to field an effective team. This will require the Navy to share the 
[mission] of ASW and reeruit new players. The other services have the players 
the Navy needs to round out the team. 

To support network-centricity, improved connectivity within and between 
different kinds of platforms is required. This allows machine-to-maehine transfer of data 
without human intervention and provides a reduction in workload and susceptibility to 
error and an inerease in speed of eommand. Joint, interageney, allied, and eoalition 
forces need to share data from space, air, surface, and subsurfaee platforms eonducting 
ASW operations. Today, these platforms may have evolved C41 systems optimized for 
their environment, but they laek the capability to share information and coordinate 
operations effeetively. 

Shared information improves the quality of information through data fusion, 
information management, and human-systems integration. This provides more aeeurate, 
preeise, and timely data required to detect, track, and engage the enemy and to reduce the 
time in the kill chain. Today, the fielded capabilities in data fusion, information 
management, human-systems integration, and networking are either teehnieally immature 
or nonexistent. 

To inerease ASW effectiveness, eommanders require a Common Operational and 
Taetieal Picture (COTP) to view the shared and fused i n f ormation and to allow 
collaboration not only within the Navy, but also with joint, interageney, allied, and 
coalition forces. The operational picture eonsists of data with longer life spans. The 
tactical picture is generally envisioned to eonsist of data with shorter life spans serving 
operators and weapons that operate in term of seconds or microseconds [Mittu and 
Segaria, 2000]. Tactical operators and their commanders want an aeeurate taetieal 
pieture, reliable and effective deeision aids, and a faster detect-to-engage sequenee. A 
COTP provides Strike Foree and Theater Commanders realistie options for force 
allocation, threat prioritization, and engagement. This is particularly important when 
considering the neeessity of joint, interagency, allied, and coalition force alloeation 
involving air, surfaee, and subsurface platforms in ASW operations. Further, a COTP 
reduees one-on-one engagements, reduees the probability of blue-on-blue engagements, 
and inereases the kill rate. This is done while shrinking the no-attack zones to engage red 
submarines which might not be possible without a COTP [Hutter, 2008]. 

There have been a number of eomments from stakeholders regarding the use of 
COTP instead of separating it into a Common Operational Pieture (COP) and Common 
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Tactical Picture (CTP). The Chairman Joint Chiefs of Staff Instruction (CJCSI) 

3151.01A [2003] defines the COP: 

A distributed data processing and exchange environment for developing a 
dynamic database of objects, allowing each user to filter and contribute to the 
database, according to the user’s area of responsibility and command role. The 
common operational picture provides the integrated capability to receive, 
correlate and display a common tactical picture, including planning applications 
and theater-generated overlays and projections. 

Clearly, the CTP is considered a subset of the COP. The COP can also show 
many other forms of information that include readiness, intelligence, reconnaissance, and 
environmental information. The overarching goal of the COP is to facilitate collaborative 
planning and assist all echelons to achieve situational awareness [CJCSI 3151.01 A, 

2003]. The Chairman Joint Chiefs of Staff Instruction 3151.01 A [2003] defines the CTP: 

An accurate and complete display of relevant tactical data, supporting a joint task 
force that integrates tactical information from the multi-tactical data link network, 
composite tracking network, intelligence network, and ground digital network. 

The common tactical picture enables command and control, situational awareness, 
and combat identification, as well as supporting the tactical elements of all joint 
mission areas. 

From a purely naval perspective, FORCEnet utilizes the term COTP when 
defining it as one of three critical areas required to support the 19 specific capabilities 
that FORCEnet is built on [National Research Council of the National Academies, 2005]. 
It was believed that the end state product should be a single application that is tailorable 
to the user’s need, whether that is strategic, operational, tactical, or logistical. This is in 
conformance with the CJCSI 3151.01A vision for the COP and the FORCEnet vision for 
the COTP. The team chose to utilize the term COTP for consistency with the FORCEnet 
vernacular. 

ASW net-centric C4I architectures operate with systems and concepts that 
predominately use either acoustics data gathered from the ocean or radio frequencies data 
gathered from the atmosphere. Unlike radio frequencies, acoustics are significantly 
affected by the medium in which they travel. In general, the ocean medium is not as 
homogenous as the atmosphere. Ocean environment and meteorological conditions at the 
sensor affect its performance. This complexity has impeded the progress in sensor 
processing automation when compared to atmospheric sensor processing. In some 
applications, transmission of larger amounts of data associated with ASW sensors is 
required when compared to radio frequency (RF) sensors. This data is transferred from 
the sensor to C4I processing. Human intervention is needed to interpret the data which 
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causes higher lateney and a higher level of false alarm eontacts. This drives differences 
in threat danger zones, targeting timelines, and asset allocations. C41 systems that rely on 
a single aeoustic sensing system ean have a large target area of uneertainty that can cause 
low probability of kill. This is because existing weapons have relatively short ranges. 
With a stand alone acoustie sensor system, sensor operators never really know if the area 
is elear, they only have a probability-based metric. However, when data from multiple 
acoustie and radio frequency sensors ean be fused, greater aecuracy and speed of 
command can be achieved. 

What stakeholders want today is a system of systems that ean be updated quickly 
and affordably as new eapabilities are required. To date, there has been funding for 
research and development; however, it has produeed little in acquisition and 
implementation. With large misconeeptions and laek of understanding, the vision of the 
real problem is not elear and future progress is hindered. There are some realities about 
the maturity of capabilities being proposed today. A serviee-oriented arehitecture (SOA) 
is needed, but signifieant effort and assoeiated data models are still required to fully 
define it. The ASW C41 ehallenge is also the result of a number of ASW systems being 
designed without a standard architecture such as the one designed to accommodate Aegis, 
Ballistic Missile Defense, and Theater Air Defense. This project assumed that the 
funding will be available, the architeetures are open, and deeisions were made based on 
best technical solution to get to a standard Joint ASW C4I Architeeture. 

B. BACKGROUND 

With the fall of the Soviet Union and the end of the Cold War in 1989, the threat 
to the United States military from submarines had waned. The states of the former Soviet 
Union did not have the resourees to deploy submarines after its disintegration whieh had 
posed a eredible threat to the United States. Until recently, the United States has had no 
other competitors that were eapable of deploying submarines that could threaten the 
United States’ interests. The disappearanee of the submarine threat resulted in the 
Navy’s realloeation of resourees assigned to anti-submarine warfare to other more 
immediate threats. An outfall of the diversion of the resourees from ASW is that the 
infrastructure that was in plaee to detect, track, and engage submarines has deteriorated. 
However, with the growth of terror groups and rogue nations, the emergenee of eredible 
economie and political competitors, and advances in technology, the submarine is again 
viewed by the United States as a elear and present threat. Over ten years ago, the Chief 
of Naval Operations testified before Congress that the “ASW holiday’’ has ended. He 
stated that submarines and mines are among the most serious threats to the Navy 
[Morgan, 2008]. Still today, in the Pacific Ocean alone there are over 250 submarines, 
and only 30% of those belong to allied nations [Benedict, 2005; Yaw, 2006]. In addition. 
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China and India have or will soon have the ability to launch nuclear missiles capable of 
delivering a nuclear warhead from submarines [Adams, 2008]. 

C. PROJECT DESCRIPTION AND DELIVERABLE PRODUCTS 

This project’s goal was to create a standard Joint ASW C4I Architecture that 
enhances the Combatant Commander’s ability to execute a mission in support of 
campaign objectives. C4I supports all aspects of the kill chain from detection through 
engagement to battle damage assessment. A standard architecture based on the Net- 
Centric Operational Environment (NCOE) Joint Integrating Concept (JIC) is provided. 
The goal of the architecture was to allow for the employment of joint networking 
capabilities at the tactical and operational level for existing and future tactical and theater 
systems to communicate effectively [NCOE JIC, 2005]. More specifically, it aligns with 
the Information Joint Enabling Construct appendix of the NCOE JIC to implement and 
enable joint network-centric ASW operations for the 2020 timeframe. 

The operational view. Figure 2, provides a high-level description of the Joint 
ASW C4I Architecture. It describes the mission, main operational nodes, and interesting 
or unique aspects of operations. Furthermore, because the Navy has decided that 
legitimate targets include enemy submarines in port, at submarine bases, and any other 
locations that support the enemy submarine they can target these with non-traditional 
Navy ASW assets. Besides the joint approach, interagency, coalition, and allied partners 
were also included. However, the cross-domain user focus was on the joint approach. 
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Figure 2. Operational View 1 (OV-1) 

This is the OV-1 for the Joint ASW C4I Architecture. It is a High-level graphical description of 
operational concept. It shows ASW operations using joint forces for traditional and non- 
traditional targets. 


It is also important to state that developing or redesigning any sensors or weapons 
was not eonsidered. The C4I architeeture was looked at in a true platform-independent, 
network-eentric fashion. It provides the eonnection between the sensors and the effectors 
that includes kinetic and non-kinetic weapon systems. 

The integrated Joint ASW C4I Architecture was tightly coupled to functional 
requirements by performing a thorough requirements analysis. This had not been done 
before in a net-centric context. The Joint ASW C4I Architecture formed the basis for a 
gap analysis which in turn allowed this capstone design team to map existing program’s 
planned capabilities to what is really needed. It provides a tool that describes interactions 
and functionality enabling war-fighter capabilities. The Joint ASW C4I Architecture 
should be used by all existing programs in managing their interfaces moving forward and 
provides the test community with a means to map system effectiveness to joint mission 
operational effectiveness. 
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D. SYSTEMS ENGINEERING APPROACH 

1. Overview 

A number of systems engineering processes were examined in evaluating an 
approach to the project. The “Vee” approach, Hatley Pirbhai, the “Spiral” approach, and 
the Systems Engineering Design Process (SEDP) as taught at the Naval Postgraduate 
School were all evaluated on suitability and applicability to the task [Blanchard and 
Fabrycky, 2006: 30, 34], Through a multi-step process, rigorous systems engineering 
methods were applied to refine requirements and to develop a set of feasible alternatives, 
evaluate those alternatives against each other, and then select a preferred alternative to be 
presented to the stakeholders for final approval. The multi-step process had to be flexible 
and iterative in nature to allow for feedback throughout the process with the intent to 
positively influence the outcome. 

All the examined systems engineering processes were found to be suitable for the 
task. However, a tailored SEDP was selected as the preferred process due to the variety 
of tools available to complete each step and the team’s overall familiarity with that 
particular process. Figure 3 shows the tailored SEDP. There are five tier two processes: 
needs analysis, value system design, alternatives generation, model alternatives, and 
alternative scoring. Each tier two process has a summary input and output deliverable. 
Each deliverable was created using its respective toolkit. The toolkit boxes do not 
include every potential option available to help complete its associated tier two process 
but is representative of what was available. Figure 3 also shows the iterative nature of 
the overall process. Each output was reviewed by the stakeholders. Once each output 
deliverable was approved, it became the input for the next tier two process. If neither the 
stakeholders nor the team were satisfied with a tier two output, the systems engineering 
effort was backed up to an appropriate tier two process and restarted. All output 
deliverables were compared to the input deliverable to check for consistency and 
traceability. The final step was a recommended Joint ASW C4I Architecture alternative 
that was provided to the ASW Community of Interest. 
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Figure 3. Tailored Systems Engineering Development Process 

The process have five steps: needs analysis, value system design, alternatives generation, model 
alternatives, and alternative scoring. Each step has a summary input and output deliverable. Each 
deliverable was created using its respective toolkit. 

2. Tailored Systems Engineering Development Process Phases 
a. Needs Analysis 

The first tier two process performed was needs analysis. The primitive 
stakeholder need was taken as an input and turned it into an effective need as an output 
through the use of numerous tools. A stakeholder analysis, threat analysis, functional 
analysis, and futures analysis were performed. The effective need statement was assessed 
by the stakeholders and the team. 
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b. Value System Design 

Upon stakeholder approval of the effective need, that deliverable served as 
input to the next step, which was value system design. The value system design began 
with identification of the major functions the system must perform. The functions were 
decomposed into sub-functions down to the lowest logical level. The lowest level sub¬ 
functions had objectives assigned. Evaluation measures were then identified to determine 
satisfactory performance of those objectives. The output of the value system design was 
the problem definition statement. 

c. Alternatives Generation 

The Joint ASW C4I Architecture value hierarchy survey was forwarded to 
the ASW stakeholders to rank order the functional hierarchy. This information helped 
to identify specific functional gaps needing materiel or non-materiel solutions for ASW 
warfighters to accomplish their mission areas. Results of the functional gap analysis led 
to the creation of a fiscal year (FY) 2020 Joint ASW C4I Architecture Baseline which 
proved to be in very close agreement with those of the ASW stakeholders. A 
comprehensive list of DoD programs of record combined with numerous strategic 
guidance documents and design studies contributed to a comprehensive list of programs 
and proposals in the alternatives generation process that could be traced back to ASW 
functional gaps. These programs and proposals included specific hardware and software 
applications and other non-materiel solutions which will close today’s functional gaps 
over the coming decade leading into FY2020 and the Joint ASW C4I Architecture 
Baseline. Brainstorming provided additional ideas for improving interconnectivity of 
nodes, data fusion, smart push and pull of ASW data, and development of a common 
operational and tactical picture. Evaluation measures and operational factors contributed 
to the differentiation of final alternative solutions during feasibility studies and risk 
analysis which led to the recommended alternative solution set. 

d. Model Alternatives 

Using the approved feasible alternatives as an input, the Model 
Alternatives step began. From research as well as hands-on experience, EXTEND was 
chosen as the primary modeling tool. Based on the developed scenario, IDEFO, and 
functional flow block diagram, performance models for each alternative were built. 
Simulation was performed to generate data related to evaluation measures developed in 
the value system. Modeling and simulation results were the output of the model 
alternatives step, which was used as the input to the Alternative Scoring step. 

e. Alternative Scoring 

Using the results from the Modeling and Simulation (M&S) step as an 
input, the alternative scoring step began. The relevant M&S results and offline analysis 
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results were inserted in a raw data matrix. From there, multi-attribute utility theory was 
used to turn raw scores into utility scores. Each alternative had a life cycle cost estimate 
developed to assist in objective decision making. The utility of each alternative had to 
take cost into consideration as the alternative with the most utility could also be cost 
prohibitive, thus it would not be the best alternative. 

/. Best Alternative 

Each alternative provided a level of utility with some associated life cycle 
cost. A utility versus life cycle cost comparison was utilized to ascertain if any 
alternatives could be clearly discarded. Remaining alternatives were assessed to see if 
one clearly stood out as a recommendation for the best alternative. The comparison of 
viable alternative utility scores versus their life cycle cost estimate, along with any 
potential recommendation for the best alternative was forwarded to the stakeholders for 
consideration. The stakeholders may accept the recommendation, pick another 
alternative or discard them all in favor of a new set of alternatives. Curriculum 
constraints prevent this capstone design team from going beyond delivery of a set of 
alternatives with a recommendation. However, the next step in the process would be to 
either implement the chosen alternative or go through the alternatives generation process 
again. 
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II. NEEDS ANALYSIS 


The needs analysis was eompleted to provide justifieation for proeeeding further 
in the design proeess and served as the cornerstone on which subsequent design and 
decision processes were built. It was also completed in order to transform the problem 
from a primitive need to an effective need. 

Before performing needs analysis it was imperative to determine if others had 
previously worked on analyzing Joint ASW C4I Architecture and what issues or 
accomplishments may have been identified in their work. Several government sponsored 
initiatives, discussed throughout this report, were discovered which served as starting 
points for this capstone project. The United States Navy’s ASW Concept of Operations 
and the Maritime Domain Awareness documents and briefings offered insight into 
operational considerations that needed to be understood with regard to C4I operational 
needs. Several stakeholders introduced this capstone project design team to the ASW 
community of interest integrated product team which set the table for a quick look at the 
issues impacting the ASW community’s C4I capabilities and C4I relative functional gaps. 
The Net-Centric Operational Environment Joint Integrating Concept and ASW needs 
statement were utilized to frame the Joint ASW C4I Architecture and with specifying 
functional areas relative to the ASW needs statement. Pertinent approved C4I programs 
of record found in the PEO-C4I Masterplan, Version 1 and the PEO-C4I 
“Co mm unications at Speed and Depth and Optical Laser Communications Status’’ 
briefing were invaluable to the search for solutions contributing to the FY2020 Joint 
ASW C4I Architecture Baseline. Many additional references are cited throughout this 
study that enhanced understanding of the ASW C4I problem set. 

One area of the effective needs statement requiring resolution is data schema. In 
the pursuit of a common data schema and data model, the DoD has explored many 
developments in the instantiation of data-oriented structures. The schema can be defined 
by what data is allowed to be included for a specific data element, a data file, a data set or 
table. Analysis of data schema was not completed because the ASW COI was already 
developing the ASW data schema. 

The needs analysis was conducted as a five part process. First, a stakeholder 
analysis was performed by developing a primitive needs statement and identifying those 
organizations that stood to gain from the success of the Joint ASW C4I Architecture 
being developed. Once the stakeholders were identified they were presented with the 
primitive need statement and asked question to identify their requirements for that need. 
Then, research was conducted, specific net-centric documents were analyzed, and the 
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system boundary was established. Later, the stakeholders were engaged in the threat, 
funetional, and future analyses. 

Second, the threat analysis identified the strengths of the enemy submarine and 
five areas of vulnerability impacting this enemy capability and the Joint ASW C4I 
Architecture. They consist of physical infrastructure (material); in construction or 
maintenance (material); during maneuver (energy); energy signatures produced (signals); 
and sensor related (signals and data). United States Navy ASW communications 
equipment and network architecture are no less vulnerable to enemy attack than those of 
the enemy submarine. Third, the functional analysis translated the stakeholder and the 
NCOE JIC requirements into detailed design criteria, helped identify the resources 
necessary in the cost analysis section for system operation and support, and created draft 
functional models. Fourth, the futures analysis was used to make educated predictions 
with respect to the future operational environment. The future environment addressed 
extends to the year 2020. This analysis was conducted to identify and discover critical 
requirements that shape and define future development of the system, provide flexibility 
and robustness in the face of a changing environment, and extend system life. Finally, an 
analysis was conducted on the draft functional models using input from the stakeholder, 
threat, and futures analysis until the revised functional models were completed. These 
analyses led to the development of an effective needs statement. 

A. STAKEHOLDER ANALYSIS 

The following sections review the organizations that would gain from the success 
of the Joint ASW C4I Architecture being developed. They can be grouped into resource 
sponsors, the acquisition community, and the user community. Figure 4 shows the higher 
echelon organizations identified. Lower tiered organizations are addressed in the 
individual sections. Policymakers for the above co mm unities may include the Assistant 
Secretary of Defense, National Information Infrastructure (ASD-NII); the Assistant 
Secretary of Navy Research, Development, and Acquisition (ASN-RD&A); and the 
Department of the Navy Chief Information Officer (DON CIO). They were initially 
reviewed for consideration as stakeholders, but it was determined that they did not stand 
to gain directly from the success of a Joint ASW C4I Architecture. Rather, they could 
use the results of this report to tailor future policy. 

In summary, it was learned as a whole from the stakeholders that reducing the 
time in the kill chain was the most important measure to achieve in a coalition and joint 
ASW C4I system. The next most important measure was accuracy. The contact data 
accuracy is initially a function of the sensor’s capability. Some stakeholders wanted this 
to be addressed. However, that was considered outside the boundaries of a Joint ASW 
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C4I Architecture. Yet, timeliness of data has a direct impact on accuracy since the area 
of uncertainty of a target grows over time. In addition, the stakeholders identified that 
integration of underwater, surface, air, and space sensor systems along with fusion of 
contact data from these systems affects the accuracy by also reducing the area of 
uncertainty. So the major focus of the modeling effort was to address timing and the 
duration of the data fusion process. 
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Figure 4. ASW Users and Stakeholders 

This organization chart provides the high level ASW organizations that stand to gain from the 
success of an ASW C4I architecture. Lower tiered organizations are addressed in the sections 
below. 


In addition to integrating sensors, the stakeholders pointed out that the weapons 
systems need to be integrated in order to optimize the use of these limited assets. The 
integration of sensors and weapons in a C4I system requires interoperability, interfacing, 
and open source considerations. 

Integration of sensors, weapons, and data fusion was taken into consideration by 
looking at existing programs of records, policy, and guidance that the stakeholders 
provided. While it is against good requirements generation practices to provide solutions, 
the team did not want to waste effort creating elements of a C4I architecture that have 
already been created or go against policy without good reason. So these were looked at 
as possible project or design constraints. 
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Cross domain communications were critical to the stakeholders. In particular, 
high bandwidth and satellites with robust availability and reliability were important. 
Further, it was pointed out by several stakeholders that communications need to include 
coalition partners even more so than joint partners because ASW battles are not fought 
without coalition partners. However, it was also pointed out that coalition participation 
in ASW C4I architecting has been sparse and the security policy has not been resolved. 

So the focus of this project is on joint participation with the idea that the coalition 
partners or the Joint ASW C4I Architecture could adapt. Communications was a major 
focus of this project and is addressed in the alternatives generation section. 

The stakeholders generally felt that a common picture was required to effectively 
utilize the information being integrated. There was some inconsistency between them as 
to whether it would be a CTP or a COP. This seemed to be dependent on their 
background and perspectives. The team decided to use the COTP for reasons provided in 
the problem statement section. Again, programs of record, policy, and other guidance 
were reviewed when selecting functionality and alternative solutions for evaluation. 

Other needs identified were training, knowledge management, human systems 
integration, role based access to services and data, archiving for intermittent or 
disadvantaged users, redundancy for network connectivity, and available space on 
platforms for the processing hardware. All of these needs were either addressed by the 
alternative solutions identified for evaluation or were considered as elements that were 
beyond the scope of this project, but could be studied as a follow-on project. 

The users and concepts of operation used today were provided by the stakeholders 
and are described in the user community section of the stakeholder analysis. New users 
and concepts of operations may need to be developed with a new C4I architecture since it 
may change the way ASW can be conducted. This was beyond the scope of this paper, 
but would be an excellent follow-on study. 

Finally, the stakeholders identified constraints and performance measures. These 
were addressed in the constraints section and the details of the measures in the value 
system section, respectively. In any of the sections that reviewed the stakeholder input, 
how that input was used or not used was addressed. 

1. Resource Sponsors 

The resource sponsors come under the Office of the Chief of Naval Operations. 
These organizations manage the user community’s prioritized needs by either funding the 
acquisition of capability or accepting and managing the risk of not funding the need. 

Their interest is maximizing the capability they can acquire across projects from their 
limited funds. Improving ASW C4I is of great interest to the resource sponsors because 
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it has the potential to provide a multiplying effeet in eapability gained. Rather than 
spending more funding on new or improved sensors or weapons capability, existing 
sensors and weapons will be much more effective with a new network-centric C4I 
architecture. This is achieved when data from existing sensors is fused, which then 
provides more accurate and timely target information. This accuracy and timeliness 
improves the effectiveness of sensors and weapons, thus providing a greater return on 
investment than if individual sensors and weapon were improved. The following 
paragraphs provide the divisions of resource sponsors from the Office of the Chief of 
Naval Operations that gain from the success of a developed Joint ASW C4I Architecture 
and whether or not they participated in this project. 

The Communication Networks Division, N6, optimizes Navy network and 
communications investments. N6 acts as principal advisor to Chief of Naval Operations 
for communications and network matters and serves as the Navy’s top level advocate for 
information management and information technology resources throughout the Navy and 
the joint environment [Deputy CNO Communication Networks, 2007]. 

The stakeholder that provided written input from Communication Networks 
Division, N6, was LCDR Kevin L Smith. Mr. Smith, who has some experience in this 
topic, felt that there must be adequate communication assets made available to support 
this particular warfare area such as satellites and bandwidth. Communications were 
made a priority as shown in the alternatives generation section. He suggests that the Joint 
ASW C4I Architecture is not nearly as important as a coalition compliant one and that 
parallel development and integration with other service and nationalities should be 
conducted. However, other stakeholders pointed out that coalition participation has been 
sparse and security policy has not been resolved. So the focus of this project is on the 
joint approach with the idea that the coalition partners or the architecture could adapt. An 
architecture that is capable of handling new and legacy systems is more realistic than 
doing concurrent parallel development. Mr. Smith felt that the ability to access a real 
time, common operational picture of the ASW effort in support of the larger campaign 
should be the end state. However, the team concurs that the type of picture, tactical or 
operational, should be configurable so the team uses COTP. The team felt that Mr. 
Smith’s desire for the Joint ASW C4I Architecture to support processing of 
environmental data, predictions of sensor performance, and sharing of tactically relevant 
information to include sensor to weapon pairing was important and was evaluated in the 
modeling section at a high level. He considers the constraints to include physical space 
for processing hardware on platforms, lean government spending, systems command 
realignment to service-oriented architecture, and Consolidated Afloat Network Enterprise 
Services (CANES) practices. These were addressed in the constraints and alternatives 
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generation sections, respectively. Mr. Smith believes that the tolerances to be observed 
include accuracy, reliability, and integration. The team considered these and used 
accuracy and integration in the value system and alternatives generation sections, 
respectively. His suggestion on the use of gliders for intelligence collection and data 
retention, acoustics intelligence, and imagery as elements to be integrated was considered 
outside the scope of a C4I system. 

The Expeditionary Warfare Division, N85, ensures that the Department of the 
Navy addresses the unique aspects of naval expeditionary operations in the world’s 
littoral [The OPNAV Assessment Process, 1993]. This capstone project design team was 
either unable to identify or convince stakeholders from the Expeditionary Warfare 
Division, N85, to participate on this project. Their lack of participation may have a little 
effect on the Joint ASW C4I Architecture since their platform view was not obtained. 

Surface Warfare Division, N86, is responsible for naval surface ship investment, 
current readiness, and modernization as well as future ship acquisition. Their goal is to 
provide a surface navy that has the capability to defeat all maritime threats to the country 
and defend way of life [N86 Surface Warfare Division, 2008]. This capstone project 
design team was either unable to identify or convince stakeholders from the Surface 
Warfare Division, N86, to participate on this project. Their lack of participation may 
have a little effect on the Joint ASW C41 Architecture since their platform view was not 
obtained. 

Submarine Warfare Division, N87, is responsible for coordinating overall policy 
for submarine force planning, programming, budgeting, and is the source of submarine 
platform and undersea warfare expertise for developing submarine platform 
requirements. N87 is the principle source of expertise for anti-submarine warfare, mine 
warfare, submarine-based intelligence surveillance and reconnaissance, and information 
warfare. They are also the lead for the anti-submarine warfare Cross Functional Board. 
They are responsible for providing expert advocacy for submarine and undersea warfare 
related research and development, acoustic and non-acoustic submarine security, warfare 
capability development, integrated undersea surveillance systems, submarine force 
structure, and oversight of submarine related program execution [N86 Surface Warfare 
Division, 2008]. 

Bob Cepek, N87, who has a moderate to expert level of experience in Integrated 
Undersea Surveillance Systems (lUSS), provided written input. He felt that the primary 
reason for the standardization of an architecture is that it allows all components, both 
tactical and theater, to communicate effectively in a timely manner. The primary 
capability lacking is interoperability. The Navy is the first benefactor of a standardized 
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C4I architecture, but at the joint level, the timely and accurate sharing of contact level 
information is a primary need. The team concurred that communications and 
interoperability was of primary importance before anything else can happen. This was 
addressed in the alternatives generation section. Mr. Cepek felt that the metrics must 
address the timely communication of information along with other standard requirements 
of the Global Information Grid such as information assurance. Timeliness was the 
priority and was addressed in the value system and modeling sections. Information 
assurance is important, however, it was not addressed this in this report due to it being a 
lower tiered requirement that could be addressed in a follow-on project. He felt that the 
Joint ASW C4I Architecture would be used to exchange the full range of information 
needed to support ASW. This would include tactical, theater, environmental and 
intelligence information. He recommended consulting Undersea FORCEnet Working 
Group recent reports and products. The team did review this information, but it was 
marked for official use only and determined unusable in this unclassified project. Mr. 
Cepek felt that the Joint ASW C4I Architecture should support data handling, tactical and 
theater communications, weapons system tasking, provision of environmental data, and 
provision of intelligence information. Further, the processing and analysis will be 
accomplished at the contact level probably in conjunction with or based upon data fusion. 
The team concurred and the major focus of the modeling effort was to address timing and 
fusion of contact data. He felt the limits on the Joint ASW C4I Architecture are costs. 
The solution set must integrate C4I components that are already assessed effective, 
exploit commercial off the shelf products and be based upon rigorous trade studies to 
control costs. This was addressed in the constraints section of this report. Mr. Cepek felt 
that the ASW C4I challenge is also to address the result of a number of ASW systems 
being designed without a standard architecture. The standard architecture is the focus of 
this project and does address legacy and new systems. 

"KC" Stangl, N87, has 30 years in ASW and associated command and control and 
five years in communication technology. He felt that ASW commanders require a 
common tactical picture with low enough latency and high enough accuracy to 
effectively multiply force effects and avoid one-on-one engagements. The latency and 
accuracy issues imply capabilities in data fusion, knowledge management, human 
systems integration, and interoperability that are either technically immature or non¬ 
existent. All of these are addressed except knowledge management and human systems 
integration. These were an important, but could be addressed by a follow-on project and 
were considered out of scope for this project. Mr. Stangl believe that geospatial and 
temporal filtering will allow for different display configurations, and mission definitions 
will define data pulls and pushes, with automated services tailored to specific roles. The 
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team agreed with this and called the common picture a COTP to imply that it is 
configurable. He believes that the constraints include computational load versus 
available real estate and bandwidth, open source versus proprietary software, standard 
data interfaces to facilitate rapid technology insertion, fleet military utility assessments, 
and information assurance accreditation and certification. These are addressed in the 
constraints section. He provided several policy and programs of record to consider that 
are addressed in the alternatives generation section. 

Naval Aviation, N88, has a process to review, validate, and prioritizes the war 
fighting requirements. The decisions are based on three major program issues: safety, 
readiness and maintainability; and mission performance. Once the proposed 
prioritization is complete, the Aviation Flag Board, comprised of senior members of 
Naval and Marine Corps aviation, meets to finalize the sponsor program proposal for 
input into the Navy Program Objective Memorandum [Evans, Lyman, and Ennis, 1995]. 
This capstone project design team was either unable to identify or convince stakeholders 
from the Naval Aviation, N88, to participate on this project. Their lack of participation 
may have a little effect on the Joint ASW C41 Architecture since their platform view was 
not obtained. 

2. Acquisition Community 

The Defense Acquisition Community designs, integrates, and procures C4I 
equipment and processing under the sponsorship of the resource organizations above. 
This community includes the technology and system development community which 
consists of systems command field activities and federally funded research and 
development centers. 

Program Executive Office (PEO), Littoral and Mine Warfare (LMW) is one of 
five PEOs affiliated with Naval Sea Systems Command (NAVSEA). The mission of the 
Program Executive Office for Littoral and Mine Warfare is to assure access in the 
littorals for the joint warfighter. In addition, PEO-LMW has two program offices that 
would benefit from the development of the Joint ASW C4I Architecture. This includes 
Program Manager Ships (PMS)-485, Maritime Surveillance Systems, and PMS-420, 
Littoral Combat Ship Mission Modules. The stakeholder that provided written input for 
the PEO-LMW acquisition community was Cecil Whitfield. He reviewed the team’s 
questions and initial primitive needs statement, but provided only editorial comments. 
His lack of comment likely had little effect on the outcome of the project since the 
program offices under PEO-LMW that are associated with this project did provide input. 

The Maritime Surveillance Systems (MSS) Program Office is involved with the 
development and maintenance of various Integrated Undersea Surveillance Systems 
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(lUSS). lUSS provides the Navy with its primary means of submarine deteetion of both 
modem diesel and nuclear submarines in littoral or broad ocean areas of interest. This 
includes efforts for both Fixed Surveillance Systems (FSS) and Surveillance Towed 
Array Sensor (SURTASS). The stakeholder that provided written input from Maritime 
Surveillance Systems was Doug Dickerson. He solicited and consolidated information 
from his C4I team. Most of his resources are expended maintaining existing C4I systems 
and managing their upgrade to the current Navy C4I programs of record such as Global 
Command and Control System- Maritime (GCCS-M) 4.x and Common Personal 
Computer Operating System Environment (COMPOSE) 3.x, from PMW-150 and PMW- 
160, respectively. However, he felt that current operational C4I systems were not 
designed to operate seamlessly with one another. Particularly when considering the 
necessity of joint operations involving air, surface, and subsurface platforms that may 
have evolved C4I systems optimized to their environment, but not for coordination with 
one another. He felt that system performance should be measured as time late as applied 
to detection, localization, and weapon on target. System availability such as robust 
satellite communications was important. All of these measures were considered in the 
value system section. Mr. Dickerson also believes that robust satellite communications is 
essential. The existing and planned systems that he provided were addressed in the 
alternatives generation section. Mr. Dickerson stated that core services include web, 
instant messaging, persistent chat, domain name service, secure mail, global address list, 
common operational picture, voice over internet protocol (IP), user authentication, and 
simple mail transfer protocol. However, with the exception of the co mm on operational 
picture, that level of detail was considered out of scope for this project. He provided 
major program of record systems that the Joint ASW C4I Architecture needs to comply 
with. These were reviewed in the constraints and alternatives generation sections. He 
felt that a new architecture, such as this project, could be an improvement of current 
Undersea Warfare-Decision Support System (USW-DSS) conceptual thinking. 

PMS-420, the Littoral Combat Ship Mission Module Program Office, packages a 
variety of technologies, many of which are produced by other program offices and 
delivered as elements of a particular mission module for the Littoral Combat Ship. The 
ASW module includes acoustic sensors such as a multifunction towed array and a remote 
towed active source, along with other detection systems and weapons designed for use 
aboard the MH-60 helicopter and unmanned surface vessels like the Spartan [Defense 
Industry Daily, 2006]. The stakeholder that provided written input from PMS-420 was 
Rich Volkert. He felt that the Joint ASW C4I Architecture needs long range unrelayed 
data transmission capability with high bandwidth capability. The end goal of net-centric 
warfare is transparent data sharing between users. Bandwidth and data transmission were 


19 



a significant consideration in the alternatives generation section. He provided 
environmental threat information that was addressed in the threat analysis section. The 
environmental characteristics to comply with include spectrum use constraints depending 
on operational site, active denial of spectrum such as jamming and anti-satellite 
operations, and the need to counter active source acoustic sensing. He also provided 
existing systems that the Joint ASW C4I Architecture needed to interface with which was 
addressed in the constraints and alternatives generation sections. Mr. Volkert also 
provided functions of the Joint ASW C4I Architecture addressed in the functional 
analysis section. He believes our constraints include legacy radio assets and limited 
links, product obsolescence, and multiple proposed relay concepts in existence but no 
clear acquisition path on what is real. His expectation of a Joint ASW C41 Architecture 
is a document laying out the minimum link needs for integrating today’s capability with a 
defined incremental path leading to longer duration relayable high bandwidth capability. 
The legacy radio asset and minimum link needs are addressed in the alternatives 
generation section. Mr. Volkert felt that a new war fighting view should be developed 
for the acquisition communities to support vice the legacy approach of developing 
capabilities that are then fitted into the existing nets. Both a new and legacy system 
needed to be considered. Mr. Volkert felt that the system tolerances include latency and 
the need to clearly define prioritization in data messaging to ensure that you do not place 
mission in hazard due to maintaining a link of lower priority. Higher level of false alarm 
and potential minimal data availability in the ASW mission drive the need for large 
distributed links and data fusion. These elements are addressed in the value system and 
modeling sections. Mr. Volkert suggests that the Navy should be able to conduct the 
detect-to-engage sequence with off board vehicles and distributed systems under remote 
control today eventually leading to engagement capability with these systems. These 
vehicles were believed to be outside the scope of the Joint ASW C4I Architecture. They 
could interface with it, but are not part of it. 

Program Executive Office, Integrated Warfare Systems (IWS) is another one of 
five program executive offices affiliated with NAVSEA. PEO-IWS delivers enterprise 
solutions for Naval warfare systems that operate within the fleet and joint force [PEO 
IWS, 2008]. PEO-IWS has one program office that would benefit from the development 
of the Joint ASW C4I Architecture. The Undersea Systems Program Office (PEO-IWS 
5.0) is involved with development of enterprise solutions that integrate various undersea 
systems. This includes surface ship undersea warfare combat systems, ASW systems 
engineering, task force ASW acquisition, and ASW C2 systems. The USW-DSS 
program is particularly applicable to this project. James N. Thompson and Raymond J. 
Curts were points of contact from PEO-IWS, IWS-5.0 (Undersea Systems). They have 
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moderate to expert experienee on ASW and C4I arehitectures. They felt that the Joint 
ASW C4I Arehitecture needs to be eonsistent with Net-Enabled Command Capability 
(NECC). This was reviewed in the eonstraints and alternatives generation seetions of this 
report. Mr. Thompson and Mr. Curts felt that metrics include quality, accuracy, 
timeliness, and authenticity of ASW related data as it is transmitted to fleet commanders 
and other users. Timeliness and accuracy were addressed in the value system and 
modeling sections. However, quality and authenticity were not addressed at this phase of 
architecture development. Rather, those could be addressed as an area of further study. 
They felt that the functions the Joint ASW C41 Architecture will perform include 
common tactical picture and decision aids. The common picture was addressed this 
project, but not the decision aids. That is suggested for a follow-on project activities. 
They felt that the Joint ASW C4I Architecture should be captured in a data format that 
can be queried, analyzed, and manipulated. Ideally, the data schema and format should 
be compatible with all other architecture data but, since there is no accepted standard and 
a large number of data structures are in use, compatibility can only be accomplished with 
a limited subset. Mr. Thompson and Mr. Curts believed that ASW is consolidating 
around the Undersea Warfare-Decision Support System as the primary C2 system for the 
mission area. This was reviewed in the constraints and alternatives generation sections. 

The Program Executive Office, C4I develops implementation guidance for 
program execution of Network Centric Enterprise Solutions for Interoperability (NESI) 
[Cox, 2005]. PEO-C4I has three program offices that stand to gain from the 
implementation of the Joint ASW C4I Architecture. These include Program Manager 
Warfare-770 (PMW-770), PMW-160, and PMW-150 - C2 Applications. Submarine 
Integration (PMW-770) is responsible for integration to submarines, primary fleet point 
of contact, installation, and delivery of the C4I capabilities to submarines [Miller, C., 
2006]. PMW-160 is the Navy acquisition and technical authority for networks, 
information assurance, and enterprise services. They provide interoperable and secure 
net-centric enterprise capabilities to the Navy, joint, and coalition warfighters 
[Wolborsky, 2005]. PMS-150 transforms operational needs into Command and Control 
capabilities for Navy, Marine Corps, joint, and coalition warfighters [Spencer, 2005]. 

Michael Hutter, Technical Director of PMW-770 (Submarine Integration), 
represented all of PEO-C4I for this study. He has 21 years in submarines practicing 
ASW and 15 years in submarine communications requirements generation, funding, 
acquisition, systems development, fielding, and testing. He felt the Joint ASW C4I 
Architecture needed to be developed because it will reduce the time in the kill chain, 
reduce the incidence of blue-on-blue, and increase the kill rate or number of detection 
and disruption of red attacks. He does not think the joint services need an ASW C4I 
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architecture. He believes ASW is a uniquely Navy Mission and a not joint mission. 

ASW is required to ensure access to eommit land forees to battle and to resupply those 
forces. While it is a predominately a Navy mission, this capstone projeet design team 
does not agree that it is solely a Navy mission. It needs to be a eoalition and joint 
mission to be effeetive. He provided interfaces, funetions, and eonstraints for those 
seetions, respeetively. For submarines, he states that limitations to eommunieations at 
speed and depth (CSD). Mr. Hutter’s view point of the situation today is that there is a 
temporary solution in place for CSD today until the holy grail of CSD is aehieved. This 
can be aehieved through technology such as satellite based optieal laser communications 
(OLC) to enable full eoverage of the speed and depth operating envelope for submarines. 
This was addressed in the alternatives generation seetion. 

Program Executive Offiee, Submarines (PEO-SUB) develops, aequires, 
modernizes, and maintains the submarines and undersea systems. Team Submarine is an 
amalgamation of PEO-SUB, the Deputy Commander, Undersea Warfare (NAVSEA 07), 
and the Deputy Commander, Undersea Technology (NAVSEA 073). The Team 
Submarine eoncept unifies the onee diverse submarine-related commands and activities 
into a single “submarine-centric” organization. Its goal is to eliminate traditional stove- 
piped struetures and processes that created impediments and ineffieieneies in the 
submarine research, development, aequisition, and maintenance communities. Team 
Submarine provides improved eommunieation among the various offices that contribute 
to the overall suecess of the United States Submarine Force One program offiee under 
PEO-SUB. A program office under PEO-SUB that stands to gain from the development 
of the Joint ASW C4I Architeeture is Program Manager Ships-425 (PMS-425), 
Submarine Taetieal Control Systems. PMS-425 develops and aequires the combat and 
weapons eontrol systems for both in-serviee and new eonstruetion ships [PEO Subs, 
2008]. 

Program Executive Offiee for Air ASW, Assault and Speeial Mission Programs 
(PEO-A) provides expertise, assistanee, resourees to program teams and represent 
exeeutable programs for air assault, air ASW, and air speeial mission to higher levels of 
management; provides evaluations, options, and recommendations on program planning 
and execution to the appropriate Milestone Deeision Authority and resource sponsor 
[PEO (A), 2008]. PEO-A has three programs that stand to gain from the Joint ASW C4I 
Arehiteeture. This ineludes Program Manager Air 290 (PMA-290), Maritime Patrol and 
Reeonnaissance Aireraft; PMA-299, ASW Rotary Wing Aireraft; and Program PMS-264, 
Air ASW Systems. PMA-290 leads programs for replacement of aireraft with Under 
Secretary of Defense for Aequisition, Teehnology, and Logistics as Milestone Deeision 
Authority [PMA-290, 2008]. PMA-299 leads the H-60 Seahawk program. The H-60 is a 
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multi-mission, ship-based naval helicopter designed to extend the sensor range of frigates 
for anti-submarine warfare [Naval Supply Systems Command, 2008]. PMS-264 leads the 
sonobuoys programs under various contracts. These include the bathythermograph, 
directional frequency analysis and recording, low frequency analysis and recording, 
directional command activated sonobuoy system, vertical line array directional frequency 
analysis and recording, and data link communications sonobuoys [Approved Navy 
Training System Plan for the Navy Consolidated Sonobuoys, 1998]. 

Defense Information Systems Agency (DISA) is a combat support agency 
responsible for planning, engineering, acquiring, fielding, and supporting global net- 
centric solutions to serve the needs of DoD. DISA is the lead for NECC. NECC will be 
the DoD’s principal command and control information technology. It will enable 
decision superiority via advanced collaborative information sharing achieved through 
vertical and horizontal interoperability. NECC is the net-centric migration path for the 
Global Command and Control System family of systems. It will use Net-Centric 
Enterprise Services (NCES) core enterprise services and will be able to exchange 
information across multiple security domains [NECC, 2008]. 

There are five systems command field activities that should participate in the 
development and fielding of the Joint ASW C4I Architecture. Each is affiliated with a 
systems command. Two are warfare centers affiliated with NAVSEA: the Naval 
Undersea Warfare Center (NUWC) and Naval Surface Warfare Center (NSWC). NUWC 
is the Navy’s research, development, test and evaluation, engineering, and fleet support 
center for submarines, autonomous underwater systems, and offensive and defensive 
weapons systems associated with undersea warfare [Naval Undersea Warfare, 2008]. 
NSWC is the Navy’s main research, development, and test and evaluation activity for 
ship and submarine platform and machinery technology for surface ship combat systems, 
ordnance, mines, and strategic systems support [The Naval Sea Systems Command: A 
Determined Team, 2008]. 

The Naval Air Systems Command (NAVAIR) provides acquisition, research, 
development, test and evaluation, and in-service support capabilities for airborne 
weapons. NAVAIR is the principal provider for the Naval Aviation Enterprise and 
contributes to every warfare enterprise in the interest of national security [NAVAIR, 
2008]. Affiliated with NAVAIR is the third systems command field activity that should 
participate in this architecture project; Naval Air Warfare Center - Aircraft Division. 
They perform research, development, testing, and evaluation for Naval aircraft systems 
and antisubmarine warfare systems, and perform associated software development [Naval 
Air Warfare Center, 2008]. 
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Space and Naval Warfare (SPAWAR) Systems Center (SSC) San Diego and 
Charleston are warfare centers affdiated with Space and Naval Warfare Systems 
Command Headquarters. They are the fourth and fifth systems command field activities 
that should participate in this architecture project. SSC San Diego develops Command, 
Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance 
(C4ISR) capabilities that allow decision makers of the Navy, and increasingly of the joint 
services, to carry out their operational missions and protect their forces. SPAWAR HQ, 
SSC San Diego, and SSC Charleston are contributing significantly to the efforts of the 
FORCEnet [Space and Naval Warfare Systems Command, 2008]. FORCEnet is the 
operational construct and architectural framework for Naval Warfare which integrates 
warriors, sensors, networks, command and control, platforms and weapons into a 
networked, distributed combat force, scalable across the spectrum of conflict from seabed 
to space and sea to land [FORCEnet, 2008]. 

United States Coast Guard (USCG) Deep Water Program stands to gain from a 
the Joint ASW C4I Architecture in its Maritime Patrol Aircraft’s command and control 
systems [Allen, 2007]. 

The Mitre Department of Defense Command, Control, Communications, and 
Intelligence (C3I) Federally Funded Research and Development Center (FFRDC) 
supports the Navy. The C3I FFRDC directs its work program toward achieving the 
DoD’s vision of an integrated command and control capability based upon C4ISR 
systems that support joint United States and multinational military operations [Mitre, 
2008]. 

This capstone project design team was unable to identify or convince stakeholders 
from PEO-SUB, PMS-425, DISA, NSWC, NUWC, NAVAIR, SPAWAR, SSC -SD, 

SSC - Charleston, USCG, and Mitre organizations to participate on this project. Their 
lack of participation caused more research while defining the needs. Ideally the team 
would have preferred to have them engaged. 

3. User Community 

The ultimate users of the Joint ASW C4I Architecture are the cue-to-kill chain 
communities. This community drives the requirements for C4I architectures. They can 
improve their tactical and operational superiority through a joint integrated open ASW 
C4I architecture. This allows for the exchange of the full range of information. This 
includes tactical, theater, environmental, and intelligence information. This information 
is needed to plan and execute missions and search strategies; coordinate undersea warfare 
operations with multiple ASW platforms; monitor prosecution of targets; assess kills; and 
perform battle damage assessment. Further, the Joint ASW C4I Architecture must meet 
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the commanders’ requirements to have current and accurate information regarding threat 
status. This community includes United States Joint Forces, Homeland Security such as 
the Coast Guard, and coalition partners who are essential to the vision of a 1,000-ship 
navy. The different user roles are identified by the Global ASW concept of operation 
recently updated by Naval Mine and Anti-Submarine Warfare Command (NMAWC). 
However, that document is classified and could not be used for this project. Therefore 
the user roles were captured through unclassified sources and may not be complete or 
current. The users’ roles drive what the data needs are and how they will be used for 
ASW operations. This will drive the data sources that need to be integrated in the Joint 
ASW C4I Architecture. Specifically the users and their roles are included the following 
paragraphs. 

Joint United States Forces Combatant Commanders are strategic theater 
commanders that have planners for air and land war that determine losses in route and 
enable prediction or success in air and land battle. For example, the Commander, United 
States Pacific Fleet (COMPACFLT) mission is to support the United States Pacific 
Command’s (USPACOM) theater strategy, and to provide interoperable, trained, and 
combat-ready naval forces to USPACOM and other United States unified commanders. 
As such, the COMPACFLT is a "force provider" to unified commanders in various 
regions around the world. Although the COMPACFLT is primarily a force provider, five 
numbered fleets and operational commanders report directly to COMPACFLT. One of 
the five numbered fleet commanders is Commander, Task Force 12 (CTF-12). CTF-12 
conducts anti-submarine warfare operations theater-wide [Commander, United States 
Pacific Fleet, 2007]. Similarly, there are CTF-69, 74, 84 supporting their numbered fleet. 

So, for example, the USPACOM has COMPACFLT with the following 
organizations to conduct ASW. Tactical Strike Group Commanders are the operational 
users in assigning and prioritizing user allocation of bandwidth and the authorized 
available frequency spectrum. Theater Anti-Submarine Warfare Co mm ander (TASWC) 
organization has experts at coordinating ASW. They are responsible for ASW planning; 
environmental prediction areas; correlations; and tasking orders, but often delegate that to 
the Anti-submarine Warfare Commander (ASWC). TASWC or ASWC develops mission 
plans based on available assets and resources, intelligence, and environmental 
predictions. ASWC afloat and ashore coordinate resource use and risk for transiting 
forces or forces in a sea-base. TASWC or ASWC hands out coordinated tasking through 
the Sea Combat Commander (SCC) to units. SCC requires the ability to communicate 
intentions, on-going actions, requirements, and results to peer level warfare commanders, 
supporting commands, and higher authority. The SCC requires the ability to rapidly send 
their directions to the ASW mission or unit commanders for implementation. 
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The units then execute the plan, provide real time status, and obtain kill. ASW 
mission or unit commanders are used for coordinated sensing, attacking, and to prevent 
blue on blue engagement. These units require the ability to rapidly receive and 
implement the directions of the SCC, obtain kill, respond to the actions of other assigned 
platforms, and provide real time status to the SCC and other platforms concerning the 
current state of the tactical situation. Assets may include submarine platforms, surface 
platforms, aircraft platforms, or Integrated Undersea Surveillance Systems (lUSS). lUSS 
includes the shore processing facilities, supporting commands, and national intelligence 
infrastructure. 

Commander, Fleet Forces Command (CFFC) mission is to generate ready Navy 
forces for assignment and provide operational planning and support to Combatant 
Commanders, articulate to the Chief of Naval Operations (CNO) the integrated Fleet 
warfighting capabilities requirements as coordinated with all Navy Component 
Commanders, and develop Fleet Concepts of Operations [United States Fleet Forces, 
2008]. The Fleet Anti-Submarine Warfare Command (FASWC) reports to CFFC. The 
command’s mission includes integrating advanced ASW networks, establish doctrine and 
new operating concepts, fleet ASW training, and assisting naval leadership with ASW 
policy. Its primary focus will be on providing standardized ASW training for the entire 
Navy, assessing ASW capabilities and readiness throughout the fleet, and in seamlessly 
implementing the latest state-of-the-art technology into ASW operations [Fleet 
Antisubmarine Warfare Command, 2004]. 

Naval Network Warfare Command (NETWARCOM) is the type commander for 
Navy networks. Networks, as warfare enablers, are becoming increasingly important to 
today’s warfighter. NETWARCOM will be the central operational authority responsible 
for coordinating all information technology, information operations, space requirements, 
and operations within the Navy [Slaght, 2002]. 

Naval Mine and Anti-Submarine Warfare Command (NMAWC) is the war 
fighting center and principal authority for the mine warfare and ASW mission. It focuses 
efforts across numerous resource sponsors, systems commands, research laboratories, 
training organizations, and operational commands to ensure Navy-wide competency in 
the mine warfare and ASW mission areas. NMAWC is the primary command through 
which issues related to mine warfare and ASW are coordinated with tactical development 
agencies and commands [Naval Mine and Anti-Submarine Warfare Command, 2007]. 

Naval Meteorology and Oceanography Command (NMOC) is an echelon III 
command under the lead of the Commander, Fleet Forces Command. NMOC is the lead 
in multidimensional battlespace awareness. They analyze and predict acoustic ranges for 
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the Navy’s ASW effort. The Commander Undersea Surveillanee (CUS), head of the 
Navy’s Integrated Undersea Surveillance System (lUSS), is an echelon IV command that 
serves under the NMOC. CUS uses and monitors sensors in the Navy’s ASW effort 
[Naval Meteorology and Oceanography Command Public Affairs, 2007], Other users or 
providers for ASW include the Intelligence Commanders and Space Warfare 
Commanders. 

The only stakeholder that provided written input from the user community was 
Greg Clarkson from Commander Undersea Surveillance. He has extensive experience 
with net-centric ASW having served as the Director of Operations for the Web-Centric 
ASW Net (WeCAN), the first joint C4I system for ASW COL He also has 27 years 
experience as an lUSS Master Acoustic Analyst. He felt that the need to communicate 
across the joint community and coalition is critical to the Navy ASW community. Mr. 
Clarkson believes that the greatest thing lacking today is cross domain communication 
capability. Security restraints and policies preventing United States and allied IP based 
communications are not only fhistrating it is likely to endanger engaged platforms or 
cause depletion of sensor and weapon resources when needed most. Joint ASW C4I 
Architecture is needed to enhance battle communication effectiveness, protect the fleet, 
and to mitigate risks of resource waste. The joint services need a Joint ASW C4I 
Architecture that maximizes the use of limited resources. This capstone project design 
team agrees with this assessment. Mr. Clarkson felt that the performance measures of a 
Joint ASW C4I Architecture should includes timeliness of reports, false alarm rates, 
actual versus requested search patterns, units pulled off search for other tasking, source 
inventory and bearing accuracy, positional accuracy, correlation accuracy, and send and 
receipt speed of communications. The timing and accuracy at a high level was addressed 
in the value system and modeling sections. However, the other performance parameters 
suggested were too low level and were not addressed here. They could be the topic of a 
follow-on study. Many constraints, functions, interfaces were provided by Mr. Clarkson 
and were incorporated in those sections, respectively. 

The Department of Homeland Security outlines the national priorities for 
achieving Maritime Domain Awareness (MDA). MDA is the effective understanding of 
anything associated with the global maritime domain that could impact the United States’ 
security, safety, economy, or environment. MDA is a key component of an active, 
layered, maritime defense-in-depth. MDA will be achieved by improving the ability to 
collect, fuse, analyze, display, and disseminate actionable information and intelligence to 
operational commanders and decision makers. It will reorient and integrate relevant Cold 
War Command C4ISR legacy systems and operational concepts with current and 
emerging sensor capabilities and applicable procedures. These capabilities will be fused 
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in a common operational picture that is available to maritime operational commanders 
and accessible as appropriate throughout the United States government. The COP is 
shared by United States federal, state, and local agencies with maritime interests and 
responsibilities. This dynamic and scalable COP will provide the appropriate types and 
level of information to the various agencies in a near-real time, customizable, network¬ 
centric virtual information grid. The United States Coast Guard comes under the 
Department of Homeland Security. They stand to gain from a common Joint ASW C4I 
Architecture [National Plan to Achieve Maritime Domain Awareness, 2005]. 

Coalition and Multi-National Forces including Canada, Great Britain, Japan, and 
Australia will gain from a common Joint ASW C41 Architecture. 

There were no stakeholders representing COMPACFLT, CTF-12, 69, 74, or 84, 
TASWC, ASWC, see, CFFC, FASWC, NETWARCOM, Intelligence Commanders and 
Space Warfare Commanders, Coalition and Multi-National Forces, or the United States 
Coast Guard. However, several of the stakeholders from the acquisition and resource 
communities had been in the user community at one time, so they were a good surrogate 
stakeholder for the user. 

B. THREAT ANALYSIS 

Threat is defined as “an expression of intention to inflict evil, injury, or damage; 
one that threatens; an indication of something impending” [Merriam-Webster, 2008]. For 
this report, the threat is an enemy submarine’s complete system capabilities and the threat 
to the C4I architecture. The threat of the enemy submarine includes elements beyond the 
submarine itself such as its command and control, country’s ideology, supply system, and 
fleet support units. Further, the threat is addressed across the life span of its operational 
use including its initial design stage, parts production and fabrication, and the launch of 
an operationally ready submarine. 

In his January 2002 article “Practical Threat Analysis and Risk Management,” 
Mick Bauer [2002] asserts, “Threat is the combination of an asset, vulnerability and an 
attacker.” Though directed more specifically to computer unique situations Mr. Bauer’s 
following points help to further define the threat to the Joint ASW C4I Architecture and 
its operational environment. Specifically the following: 

An asset is anything you wish to protect. In information security scenarios, an 
asset is usually data, a computer system or a network of computer systems. We 
want to protect those assets’ integrity and, in the case of data, confidentiality. 
Integrity is the absence of unauthorized changes. Unauthorized changes result in 
that computer’s or data’s integrity is compromised. We also want to protect the 
confidentiality of at least some of our data. This is a somewhat different problem 
than that of integrity, since confidentiality can be compromised completely 
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passively. Step one in any threat analysis, then, is identifying which assets need 
to be protected and which qualities of those assets need protecting. Step two is 
identifying known and plausible vulnerabilities in that asset and in the systems 
that directly interact with it [Bauer, 2002]. 

Our analysis of the enemy submarine and support organization assets was 
considered for two specific phases of the enemy submarine’s life cycle: before its 
subsystems are completely integrated (pre-full operational capability) and after it has 
become a fully operational unit capable of conducting sea-going missions (full 
operational capability). 


Operatioiial 

Sub-System 


Enemy Submarine 
Pre-Fuil Operational Capability 


Personnel 


Training 


Logistics 


Documents 



Physical 



Infrastructure 


Propulsion 



Program 

System 



Managers 


University 

Education 



Transport 



Building 



Storage 


System 



Plans 



Shelters 


Maneuvering 



Acquisition 

System 



Specialists 


Military 

Schools 


Tracking 

System 


Financial 

Records 


Piers 


Sonar 

System 


Scientists 


Vendor 

Training 


Security 

System 


Agreements 


Dry 

Docks 


Navigation 

System 


Engineers 


System 

Courses 


Packaging 



Operational 

System 


Acceptance 


Maintenance 

Buildings 


Weapons 



Foreign 



Instructional 

System 



Advisors 


Guides 


Confimand & 
Control Facilities 


Communication 

System 


Designers 


Fixed 

Communications 

Peripherals 


Fuel 

System 


Figure 5. Pre-Full Operational Capability 

This diagram detaiis six areas of major importance to the enemy forces abiiity to produce a fliiiy 
operationai submarine - operationai sub-systems, personnei, training, iogistics, documents, and its 
physicai infrastructure. 


Figure 5 identifies six pre-fully operational capability areas and their hierarchical 
decompositions. The pre-full operational capability areas include: operational sub¬ 
systems, personnel, training, logistics, documents and physical infrastructure. 
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Operational sub-systems include all hardware systems and equipment, which, when 
properly integrated, form a fully operational mission capable submarine. Personnel are 
those individuals and teams that contribute to the designing, crafting, integrating and 
ultimately controlling the operational performance of the submarine at sea. Training 
offers the ways and means for attaining skill sets required to conduct submarine 
operations and most efficiently operate the subsystems being placed onto the submarine. 
Logistics addresses the secure movement and tracking of consumables, parts, and 
subsystems from construction to final delivery and storage. Documentation is required to 
properly construct the vessel, acknowledge financial expenditures, show program 
information, and exchange operational acceptance for the submarine system. The 
enemy’s physical infrastructure includes command and control buildings, 
communications peripherals, storage and maintenance, as well as, dry docks and piers. 

In the full operational capability phase submarines play key roles in strategic 
military operations and are often politically sensitive to global diplomatic relationships. 
Rogues of the world’s naval forces, submarines quietly navigate the world’s seaways 
above and below the ocean’s surface independently or in close proximity to a fleet or 
battle group. A submarine is specifically built to operate and endure long periods of time 
under water [Offley, 2008]. To understand this undersea threat it is most important to be 
aware of its operational subsystems and their collective dangers posed on friendly forces 
and the conduct of submarine military operations. The submarine threat is capable of a 
myriad of sea and undersea missions. Figure 6 provides a detailed look at disruptive 
activities submarines could be engaged in around the world. Each activity represents an 
important input to overall defensive and offensive strategies of the adversary. The 
activities were broken down into two categories: disrupt sea lines of communication and 
disrupt joint military operations. 
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Figure 6. Submarine Disruptive Activities 

Submarines have the capacity to create disorder to sea lines of communication and joint military 
operations through offensive and defensive actions, harassment activities, and attack missions. 


Disruptions within sea lines of communieation include unsafe enemy submarine 
sea keeping practices forcing surface ships off course, mine laying activities, 
psychological operations, and weapons launch and the conduct of harassment activities 
such as embargo and communications. These activities could wreak havoc on 
commercial and military shipping alike, having severe impacts on political and economic 
venues of affected areas. Additionally, it is expected that the enemy will conduct 
defensive and offensive actions to disrupt joint military operations. Defensive actions 
could include research, the deployment of sea mines, conduct of training exercises, or the 
performance of intelligence, surveillance, and reconnaissance missions. Offensive 
actions would include the deployment of missiles or torpedoes, the use of small arms 
weapons, or simply running their submarine at perspective targets to cause dangerous 
navigational situations. 

Submarines move freely through sea space looking to gain positional advantage 
over a single quarry at depth, on the sea surface, ashore and space-based targets. 
Operational functions of the enemy threat consist of delivering weapon, observing 
targets, maneuvering the boat, and communicating information. The submarine, by its 
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nature, performs its duties with utmost secreey and sensitivity to its environment. It 
observes its environment acoustically, visually, and electromagnetically. It relies on its 
keen sense of situational awareness in its search for contacts while maintaining proper 
positioning within the x, y, and z axes of the water column to best perform its passive, 
observational duties. These duties may include surveillance and reconnaissance; release 
of weapons like mines, torpedoes, missiles; and communication of tactical or strategically 
significant information. Communication by enemy submarines is expected to be 
infrequent, if at all. The joint and coalition maritime forces must be ready to receive 
these signals, decrypt as necessary, or jam if in naval ASW force’s best interest to protect 
assets. One thing is certain, expect a submarine to be operating where it presents a large 
number of safety risks to operational forces and commercial shipping while ensuring 
multiple escape routes for its own survivability. 

“The identification of system elements whose required performance may exceed 
demonstrated limits can be grouped into four classes of critical characteristics of systems 
functional elements: signal, data, material, and energy” [Kossiakoff and Sweet, 2003: 
209]. It is this capstone project design team’s assertion that these four elements are the 
keys to accurately identifying not only the vulnerabilities of the enemy submarine threat, 
but the threat to the vulnerabilities of the Joint ASW C4I Architecture systems and 
subsystems as well. The enemy threat is by its own nature and operational environment 
vulnerable to being located, identified, and, in time of war, destroyed. Figure 7 expands 
on the “big four” elements offered by Kossiakoff and Sweet by breaking out five areas of 
vulnerability for further consideration: physical infrastructure (material); in construction 
or maintenance (material); during maneuver (energy); energy signatures produced 
(signals); and sensor related (signals and data). These vulnerabilities will be exploited in 
anti-submarine warfare operations. They include not only the enemy submarine, before it 
is actually constructed and equipped, but also once it is deployed. 
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Figure 7. Vulnerabilities of the Threat 

Submarines are at risk to operational delay, attack, and destruction in five distinctly different areas 
including the physical infrastructure of its supporting facilities, while under construction or 
maintenance, during maneuvering activities, from energy signatures it produces, and sensor related 
activities. 


The enemy force’s physical infrastructure spans beyond the submarine pier. It 
includes numerous communications sites, command and control facilities, and fueling 
and resupply piers. With regard to the submarine threat and its need to be sustained and 
maintained, it is recommended that exploitation be carried out on “other consumables” by 
locating and targeting production sites, the physical delivery vehicles, and the specific 
system integration sites. Destruction of transport vehicles and the parts or complete sub¬ 
system could represent the delay or cancellation of the entire submarine as a whole. Loss 
of a key component could be critical to fielding this initiative. While the submarine 
threat is underway, during maneuver, it is at risk to environmental conditions; its own 
speed of advance; while conducting at-sea resupply; and its own depth limiters bounding 
a more specific operational area of the water column. Two very similar but differing 
areas of vulnerability are energy signature produced and sensor related. Energy 
signatures produced includes acoustic, machine noise, radio frequency spectrum, 
infrared, and visual cues, night or day. The ability to identify these signatures and locate 
their origins is vital to successfully to exploiting them. The enemy’s choice of sensor 
could actually help to expose his presence; hence, sensor related elements, such as active 
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and passive sensing, directional and range finding, and the use of periscope and the mast 
used for electronic surveillance measures mast, are of significant importance. ASW 
forces should seek to interact with all enemy sensors to better detect, locate and engage 
enemy submarines at the furthest ranges possible. 

The threat will not always be under power such as when it is simply drifting with 
the current or loitering on the sea bottom. It may be in other vulnerable states such as if it 
were not making way in a navigable sea lane, being pier side, or as a surface contact. If 
recognized it may be an easy target. Further, it could be identified, tracked, and 
cataloged by its own boat noise signatures, while communicating, from its exposed 
surface area or environmentally-induced visual cues such as waves, thermal signatures, 
and bioluminescence trails. 

Weapons ranges need also be considered when determining the enemy 
submarine’s intelligence, surveillance, and reconnaissance or weapons engagement 
positions. Over the horizon targets, land and sea, will require much larger anti-submarine 
search areas than those with line-of-sight (LOS) targeting solutions. The close-in targets 
offer additional operational shortcomings in that the prey will have limited warning and 
equally small reaction periods to thwart enemy actions. 

ASW is a team sport - requiring a complex mosaic of diverse capabilities 
in a highly variable physical environment. No single ASW platform, system, or 
weapon will work all the time. A wide spectrum of undersea, surface, airborne, 
and space-based systems to ensure that we maintain what the Joint Chiefs of Staff 
publication Joint Vision 2010 calls “full-dimensional protection.” The undersea 
environment, ranging from the shallows of the littoral to the vast deeps of the 
great ocean basins - and polar regions under ice - demand a multi-disciplinary 
approach, subsuming intelligence, oceanography, surveillance and cueing, 
multiple sensors and sensor technologies, coordinated multi-platform operations, 
and underwater weapons. Most importantly, it will take highly skilled and 
motivated people [Morgan, 2008]. 

Our threat can remain submerged indefinitely but is controlled by its own 
operational systems’ limiters, such as, fuel efficiency; battery duration and life cycle; air, 
food, and water for crew survivability; weapons sustainability, communications; and 
navigational subsystems. Exploiting these operational shortcomings will help to address 
their operating areas, the conduct of their missions, and offer opportunity to impede their 
effectiveness. The submarine’s operational value is limited only by its crew’s ability to 
stay hidden in the world’s seaways. The ability to communicate accurate and timely 
threat information will be significant when attempting to frustrate the plans of global 
submarine threats. 
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C. FUNCTIONAL ANALYSIS 

A functional analysis was completed to help translate stakeholder requirements 
into detailed design criteria and to help identify the resources necessary for system 
operation and support. The process followed for the functional analysis is displayed in 
Figure 8. This process was started by analyzing the primitive needs statement. After 
that, research was conducted on net-centric requirements, constraints, and interfaces. 
Specific net-centric documents were analyzed, the system boundary was established, and 
draft functional models were created. Finally, an analysis was completed on those draft 
models using input from the stakeholders, threat analysis, and futures analysis until the 
revised functional models were completed. 



Figure 8. Functional Analysis Process 

The Functional Analysis Process consisted of conducting research, analyzing key documents, 
establishing a system boundary, and creating draft functional analysis products. Completion of 
those products prompted another analysis which led to the completion of the revised products. 


The stakeholders asked this capstone project design team to build a net-centric 
architecture. For this reason, research was conducted and the NCOE JIC, the Net-Centric 
Environ m ent (NCE) Joint Functional Concept (JFC), and the Tactical Wireless Joint 
Network (TWJN) Concept of Operations (CONOPS) were identified as important net- 
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centric documentation. The NCOE JIC presents the concept of a net-centric operational 
environment and lists the capabilities that a net-centric architecture should provide 
[NCOE JIC, 2005]. The NCE JFC identifies the principles, capabilities, and attributes 
required to function in a net-centric environment [NCE JFC, 2005]. The TWJN 
CONOPS brings more fidelity to the NCOE JIC regarding the employment of wireless 
joint networking capabilities [TWJN CONOPS, 2007]. An analysis of those documents 
allowed for identification of the top-level functions the system must perform in support 
of the Joint ASW C4I Architecture. 

Analyzing the aforementioned documents allowed the system boundary to be 
identified, which established the interfaces between the Joint ASW C4I Architecture and 
other systems. Establishing the system boundary helped to determine what functions the 
system accomplishes and provided the justification for the components that are 
implemented in the system. Overall, the functional analysis provided the basis for 
developing innovative alternatives because how the Joint ASW C4I Architecture 
accomplishes these functions was not specified. This allowed for the design and study of 
systems independent of any specific technical solution. 

1. Requirements 

In order to build a net-centric system that meets stakeholders’ expectations, the 
capabilities and requirements that are needed for the C4I system were defined. Based on 
research and feedback from the stakeholders, five main capabilities that are required for a 
net-centric system were defined. From these capabilities, seventy-eight top level 
requirements were identified to be necessary in building a net-centric architecture. All of 
these capabilities and requirements for a net-centric system are shown in Appendix B. 

2. Constraints 

Constraints are factors that lie outside the control of this capstone project design 
team but have a direct impact on the system design effort. The Joint ASW C4I 
Architecture will not be used within a functional void. It functions while being contained 
by many factors contributing to its overall cost, scheduling, and performance. It is 
certain that proposed alternative solutions must stand up to the rigors of five specific 
constraints: requirements definition, system acquisition, test and evaluation, fielding, and 
ending with maximum utility to the ASW warfighter. Topical controlling factors 
considered in this study, depicted in Figure 9, calls for the Joint ASW C4I Architecture to 
be: conformal to nature; limited by its own physical system and subsystem attributes; 
regulated by doctrine; stressed in operational use; and impacted by man-made influences. 
ASW stakeholder constraints, specific to the Joint ASW C4I Architecture, are 
consolidated in the below sections. 
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Figure 9. Constraints on the Joint ASW C4I Architecture 

Each system and subsystem applied to the Joint ASW C4I Architecture is constrained by cost, 
schedule, or performance characteristics and demands resulting from natural events, physical 
limiters, doctrinal guidelines, operational controls, and man-made C4I countermeasures. 

a. Natural Constraints 
(1) Space 

Nature surrounds all conceivable applications of the Joint ASW 
C4I Architecture from space to mud. Sound and electrical impulses must travel through, 
over, or between four transmission mediums - space, air, sea, and land - to affect the art 
of communicating. The space environment can be characterized as a non-atmospheric 
entity devoid of weather effects but greatly affected by temperature extremes and sun- 
originated electromagnetic energies interfering with all radio frequency signals. This 
area outside of the earth’s stratospheric layer offers opportunity to place satellite 
communication systems at elevations and geostationary or polar transiting orbits to 
maximize beyond line-of-sight data relaying capabilities. This technology comes at 
considerable cost for research and development, operational sustainment, and system 
maintenance. Communicators need to consider distance and speed problems when 
planning satellite support to ensure the most efficient use of data rates and frequencies in 
order to reduce operational time latency issues. Once a safe operational haven, space has 
become a target-rich environment for enemy opposition to counter both commercial and 
military satellite-based communications tools with intrusion or destruction capabilities. 
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(2) Air 

Communication through the air environment has received the most 
attention relative to improving ways and means to communicate data through its 
atmospheric medium both above and below the tropopause. This is an area of great 
variability resulting from ever changing atmospheric parameters and resultant weather 
features. Precipitation rates, lightning, high winds, turbulence, temperature, and humidity 
all effect the path of radio frequency energy as it travels between known transmit and 
receive locations. Typically, excessive precipitation greatly reduces expected 
transmission ranges since water molecules absorb or diffuse electromagnetic energy. 
Lightning activity may cause intermittent interference with transmission activities or 
result in complete loss of communications at transmit or receive sites as a result of a 
direct lightning strike. High winds and turbulence mainly impact the operational use of 
communication systems and platforms which carry them ashore, at sea, or in flight. In 
some cases, systems may be redesigned to permit communication in worst case wind 
events. Understanding temperature and humidity values above the earth’s surface may 
offer insight into the occurrence of extended or shortened radio frequency 
communications ranges due to the atmospheric phenomena ducting. Ducting essentially 
traps radio frequency energy within an invisible tunnel. Ducts can be at the earth’s 
surface or elevated. When correctly using transmitters and receivers within the duct, 
extended ranges are expected. Otherwise communication ranges could be significantly 
less. 

(3) Sea 

Natural constraints within the sea are derived from the sea surface 
and wave activity; the physical and chemical properties of the water mass; and the depth 
and type of seafloor. All contribute to how well sound travels through water and what 
ranges it may be detected. The sea surface is the upper boundary for underwater sound. 

It represents the operational playing field for naval surface platforms. High sea states 
may result in the inability of these ships to perform operational ASW detection missions. 
As for the water column, it is not uniform in salt content, temperature, and clarity. Its 
sound velocity profiles change with current, time of day, sea state, locations of land 
masses, biologies, fronts, and eddies. The lower boundary of the water column is the 
seafloor. Its bottom type is critical to sound energy absorption rates. Hard bottoms offer 
an excellent probability of limited loss of energy and extended range. Mud floors ensure 
that much of the energy is absorbed and a marked loss of energy directed at the bottom. 

Radio frequency energy does not penetrate water very far; 
therefore, alternate communication methods at speed and depth constraints are needed. 
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Sound energy can be received hundreds of miles away from its originating source. 

Similar to that of air, sound energy can be trapped in sound channels to obtain extended 
ranges below the ocean’s surface. This energy trapping is the result of several types of 
gradient features resulting from isothermal or isohaline conditions. As in the air, sensors 
placed within the trapping region or duct is able to maintain contact with noise producers. 
If outside of these ducts other operational Sound Navigation and Ranging (SONAR) 
detection techniques are needed to be used such as bottom bounce or direct path. Bottom 
features such as seamounts and deep canyons reflect or absorb sound energy, further 
complicating the detection problem. 

Deep water offers relatively quieter listening conditions, whereas 
littoral shallow water areas are known to be extremely noisy, making the task of locating 
and identifying specific underwater targets nearly impossible. It is expected that the 
ASW future lies in the detection, control, and engagement of subsurface targets operating 
near or within these noisy, heavily traveled bodies of water. 

(4) Land 

For the most part, the land environment communication mirrors 
those already provided in the air and sea sections with several key discriminators. Radio 
frequency energy has the limited ability to travel through solid stone to pass imagery and 
voice data to underground users. Land masses interface with both the sea and air 
environments from ocean shorelines to the highest mountain elevations. Elevation is 
important to attain greater line-of-sight communication ranges, making higher land 
elevations important for over sea communication needs. 

b. Physical Constraints 

Size, weight, and power attributes determine where the Joint ASW C4I 
Architecture may be used operationally. Stakeholders desire to have the most efficient 
communication tool kits with high data rates, high frequencies, and minimal data 
latencies. The Joint ASW C4I Architecture is limited by available real estate at shore 
sites and facilities, and cubic space obtainable on current or planned naval platforms. 
Today’s platform commanders subscribe to the zero sum gain law of placing new 
systems into platform specific use regardless of reduced size and weight claims being 
marketed by technology vendors. It is understood that the Joint ASW C4I Architecture is 
only as good as improvements made for the intermittent, disadvantaged, and low 
bandwidth communicator. 

Shaping of communication systems has permitted unique conformal 
antenna variations though limited to available surface areas of bulkheads, hulls, and 
superstructures. Typically, larger antenna systems offer higher bandwidth capabilities 
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with larger data rates. Cumbersome dish antennas require firm ground or large naval 
deck space capable of supporting its weight and power needs. Aircraft carriers and ships 
uniquely constructed for at sea communication are able to support medium to large 
communication interface tools. Aircraft and smaller combatant surface platforms make 
use of small to medium sized tools, with submarines having even smaller areas available 
for C4I tools. 

Communication systems performance attributes such as data throughput, 
high frequency transmissions, and improved data latency may be enhanced with large 
antenna systems but may be of limited operational utility. The exception to this could 
occur through the enhancement of smaller communication systems such as burst 
communication techniques, on the move technologies, software-driven automations, and 
improved digital interface formats. Internal rack mounted communication systems such 
as modems, transmitters, receivers, and tactical interfaces are faced with similar size, 
weight, and power issues as platform commanders seek to benefit from the latest 
communication tool expected to offer greater interoperability and improved situational 
awareness. 

c. Doctrinal Constraints 

Federal doctrine, associated laws, and contractual and acquisition 
responsibilities all contribute to putting the most cost-effective system into the ASW 
operator’s hands to fill the identified capability gap. Operational needs are put into 
motion by the ASW community through timely doctrinal driven actions to derive 
quantitative, qualitative, and functionally correct data sets. If the Joint ASW C4I 
Architecture is viewed by the Navy, and the Theater Combatant Commanders it supports, 
as critical to future operations it will be raised to the United States Secretary of the 
Navy’s level for consideration, approval, and placement into the Navy’s overall budget 
submission. Although completely sponsored by Navy leadership the proposal would 
require validation by the Joint Chiefs of Staff before it is submitted to Congress by the 
Secretary of Defense. Once submitted to Congress and approved as law, the President’s 
budget can be enacted with the proposal receiving the necessary funds for acquisition and 
fielding. 

A key to successfully gaining program approval is to meet the demanding 
Program Objective Memorandum (POM) schedule to gain the necessary operational and 
fiscal support within the requisite timeline. POM fiscal year 2010 has already been 
submitted. It will be imperative to provide inputs to the next programmed budget 
estimate submission in the next fiscal year. 
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There are different ways to field any or all of the proposed alternative 
solutions. Doctrine templates the requisite staffing actions needed to achieve a successful 
fielding of an alternate solution to address the ASW community’s operational C4I 
capability gap. Cost, schedule, and performance level debates will be conducted at the 
highest levels of government to ensure the proper spending of taxpayers’ money in regard 
to the Joint ASW C4I Architecture. 

d. Operational Constraints 

Security, force levels, availability of C4I tools, and operational demand 
for data were considered the most critical constraints addressed. Once operational, the 
Joint ASW C4I Architecture needs to respond to all security needs of the ASW force. 
Security includes, but not be limited to, information assurance consisting of availability, 
integrity, confidentiality, non-repudiation, and authentication. Depending upon the 
nature of operation, certain users may require limited access to special data sets and the 
assurance that it is not compromised in any way. Submarine operations and missions 
they support tend to be placed in higher classification areas. The Joint ASW C4I 
Architecture must conform to this requirement. The classification of blue submarine 
positions can range from secret to sensitive compartmented information because of 
unique submarine limitations that affect the classification of all track data sent from the 
submarine. It is recognized that current security policies prevent United States and allied 
forces from effectively communicating. Network security aside, many coalition and 
allied partners do not have the required network infrastructures in place to use 
information technology and satellite communication solutions. This capstone project 
assumes that those policies and infrastructures will be modified by 2020. Therefore, they 
were not treated as constraints. 

The force level or number of communication nodes participating in any 
given operation is critical to the overall success of the Joint ASW C4I Architecture. Too 
many users of the Joint ASW C4I Architecture could lead to bandwidth restrictions, 
spectrum realignment, and use of standard data interfaces to facilitate rapid technology 
insertions for improved interoperability. Force level would determine the type and 
availability of specific C4I tools that would be driven by system command realignments 
to initiate compliance of all naval platforms to the CANES and the requirement to 
conform to the service-oriented architecture model. 

A key metric of success for the Joint ASW C4I Architecture is its ability 
to meet the ASW communicator’s demand for data during operations normal and above. 
The more individual users, the more capable the Joint ASW C4I Architecture must be. 
Timely, accurate data delivery to each and every operational user is paramount. 
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e. Man-Made Constraints 

Man-made contributions must also be considered as they pertain to 
constraints on the Joint ASW C4I Architecture’s levels of effectiveness. For every action 
there is a reaction. The United States blue force has been able to adjust to opposition 
force C4I system capabilities in the battlespace. They can expect no less from their 
opposition. They have well established means to interfere with radio frequency signals, 
conduct deception operations, produce misleading propaganda, and perform destructive 
acts at will. 

Jamming of radio frequency signals is commonplace in today’s 
battlespace. The Joint ASW C4I Architecture must automatically realize this counter 
action, react, and move its operational users seamlessly into a new signal frequency. The 
Joint ASW C4I Architecture utilizes low probability of intercept and low probability of 
detection devices where practical and necessary. The Joint ASW C4I Architecture is 
expected to rely heavily on web-based IP interactions, making it imperative that the 
architecture is secure from enemy information operations and hacking. 

Given today’s demand to multitask, ASW C4I consumers want even more 
data. Opponents will take advantage of all available communications sources and 
networks in an attempt to deceive and keep friendly forces from knowing their true 
intentions. The Joint ASW C4I Architecture must be designed to recognize deceptive 
activities and counter them in order to understand the enemy’s real actions and activities. 
Current events prove every day the utility of enemy propaganda to sway the hearts and 
minds of loyal supporters. ASW operators must receive accurate reporting from which to 
make correct operational decisions. The Joint ASW C4I Architecture makes forces 
mindful of enemy propaganda and take steps to thwart it in a timely manner. 

Lastly, the enemy’s ability to destroy all or part of the Joint ASW C4I 
Architecture must be considered. If communication subsystems are lost, the system must 
be pre-planned, self-healing, and offer secondary backup solutions for continued, 
unbroken C4I services to ASW operators. Edge operators and their C4I systems are 
envisioned to be lost initially although recent events indicate opposition submarine ability 
to get inside operational screens to remove high value communication assets. 

Our alternative solution topologies offer several workable proposals to 
address these scenarios. It is imperative for them to offer C4I users diverse network 
connectivity and survivability using redundancy and replication. It is also imperative for 
them to be multi-communication path capable with voice, radio, beyond line-of-sight, and 
line-of-sight communications. It must maintain threshold-level communications despite 
increasingly sophisticated enemy countermeasures consisting of electromagnetic 
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interference; high altitude electromagnetic pulse; anti-satellite operations such as denial 
of relays; and active homing systems similar to high-speed anti-radiation missile type 
threats. 

3. Interfaces 

The ASW community requires a more complete, well structured C41 system for 
the year 2020. It is envisioned that the Joint ASW C4I Architecture will remain 
constrained by current atmospheric phenomena, space weather events, signal 
transmission physics at the air-sea interface, and at-sea motions of communications nodes 
afloat. As such, communications interfaces must more capably bridge these 
environmental and physical constraints. Space based systems offer over the horizon 
beyond line-of-sight communications relay tools with inherent time delays in operational 
data transmission and receipt. Improvements in hardware and software applications are 
viewed as areas that increase data throughput capacities for users operating under 
different frequencies and communications channels. Terrestrial and maritime 
communications devices and techniques need to challenge the limits of physical 
dimensions and atmospheric conditions to maximize speed and capacity of data 
transmissions for tactical line-of-sight links and more strategic beyond line-of-sight 
communications networks. The air-sea interface represents one of the final challenges of 
the ASW community to attain communications at speed and depth. Several underwater 
communications devices and buoys are expected to bridge the acoustic to radio frequency 
energy gap of the air-sea interface and represent areas of critical importance to 
communicating with and from submarines. 

Radio frequency and acoustic energies provide means to transmit data between 
platforms at various frequencies, speeds and capacities. These communications provide 
wireless pathways networking ASW communications nodes with any and all 
communications devices around the world. Each communication path is capable of 
simultaneous two-way communications. These communication paths are used in the 
Joint ASW C4I Architecture to receive intelligence, surveillance, and reconnaissance 
sensor data which is fused and added to a common operational picture. The same 
communication paths are used to disseminate the common operational picture to all 
United States, NATO, and coalition force maritime and terrestrial nodes. At the direction 
of the strike force commanders, each user uses that information to track and engage 
submarine threats using the weapon assets and combat systems available to them on their 
individual platform. ASW platform specific combat systems use the submarine radio 
frequency system by way of internet protocol and messaging paths from broadcast 
control authorities ashore using the extremely high frequency, super high frequency, ultra 
high frequency, high frequency, low frequency, and very low frequency. 
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The United States Navy must take advantage of all maritime, terrestrial, 
and spaee based relay devices, receivers, transmitters, fusion devices and graphic displays 
to be interoperable, multi-frequency capable with all C4ISR systems in use by U.S joint 
forces, as well as, coalition forces in the year 2020 and beyond. All sensor transmissions 
must be compliant with joint communications standards permitting on time delivery and 
reporting of target information for the creation of up to the second common operational 
pictures for the ASW community and its supporting operational units. Antenna systems 
need to take on platform conformal, streamlined physical dimensions conscious of size, 
weight, and power demands while permitting maximum throughput of information as 
permitted by the lowest common denominator for bandwidth receipt - the operational 
ASW community communicator. The ASW operator utilizes data and information 
collected from the various platform sensors to interface with the joint C4I systems 
intended to fuse and disseminate tactically and strategically significant data to the 
warfighters, command authorities, and intelligence community. 

4. Functional Hierarchy 

The next step in the functional analysis was the completion of a draft functional 
hierarchy. With the draft functional hierarchy complete, an iterative analysis using the 
stakeholder analysis, threat analysis, and futures analysis was conducted until the revised 
functional hierarchy was completed. 

In the revised functional hierarchy, the system was decomposed into five top-level 
functions: provide connectivity; perform information operations; optimize network 
functions and resources; transport ASW information from end-to-end; and provide ASW 
data and information management. These functions were decomposed as displayed in 
Figure 10. 


44 




Figure 10. Functional Hierarchy 


This figure displays the complete functional hierarchy after analysis of key documents and stakeholder input. The top five functions are 
provide connectivity, perform information operations, optimize network functions and resources, transport ASW information from end to end, 
and provide ASW data and information management. 
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The definitions of the top level functions are: 

A.l - Provide Connectivity: This function physically connects the different elements of 
the system together. This includes connecting all communication nodes, interfacing with 
sensor and weapon systems, and connecting to external networks. 

A.l - Perform Information Operations: JP 3-13 defines information operations as, 
“The integrated employment of the core capabilities of electronic warfare, computer 
network operations, psychological operations, military deception, and operations security, 
in concert with specified supporting and related capabilities, to influence, disrupt, corrupt 
or usurp adversarial human and automated decision making while protecting our own” 

[JP 3-13, 2006: GL-9]. In the Joint ASW C4I Architecture, this function establishes 
aspects of information operations intended to provide a secure and protected network. 
This includes computer network defense, electronic protection, information assurance 
and physical security. This function establishes aspects of information operations 
intended to provide a secure and protected network. 

A.3 - Optimize Network Functions and Resources: This high level function prioritizes 
network functions and resources and provides access based upon the roles and 
responsibilities of each individual user. This function allows commanders and 
warfighters to have the access and resources they need in combat situations [NCOE JIC, 
2005: 44]. 

A.4 - Transport ASW Information from End-to-End: This function includes the 
transportation of information into, out of, and throughout this dynamically changing 
network [NCOE JIC, 2005: 44]. 

A.5 - Provide ASW Data and Information Management: This high level function 
includes the exchange, fusion, display, and storage of all data and information associated 
with the system. 

The definition for each of the lower level functions can be found in Appendix E. 

The NCOE JIC was utilized as a baseline for the functional hierarchy and 
modified it based on stakeholder input and because of areas of disagreement were 
identified. There were two main areas where this capstone project design team disagreed 
with the NCOE JIC. Firstly, since Joint Publication 3-13 defines electronic protection as 
a supporting function of Information Operations, the function Provide Electronic 
Protection was moved from a Tier 1 function to a Tier 2 sub-function of Perform 
Information Operations. Secondly, as the IDEFO model was built it was discovered that 
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the Transport ASW Information from End-to-End sub-function did not fit well at the Tier 
2 level creating a flow complexity that was easily overcome by elevating it to a Tier 1 
function. Additionally, the NCOE JIC provided a comprehensive set of capability 
requirements that reside in the realm of doctrine and training under the title of knowledge 
management. The team focused on the system’s ability to provide information 
management, which precluded the inclusion of many knowledge management capabilities 
found in the NCOE JIC into the functional hierarchy. 

The NCOE JIC divided capabilities into three distinct areas: knowledge 
management, network management, and information assurance. As previously stated, 
knowledge management was not addressed due to the non-materiel aspects of many of 
the described capabilities. An inconsistency discovered was the inverse way the NCOE 
JIC addressed information operations. Per the Joint Publication 3-13, information 
assurance is a core function of information operations along with computer network 
defense, physical security of the system, and electronic protection. The NCOE JIC 
inserted these capabilities underneath information assurance. Provide Information 
Operations, found in the NCOE JIC, was changed to Perform Information Operations to 
be in alignment with the Joint Publication 3-13. 

An area of divergence from the NCOE JIC was in the assumption that the network 
is established. The NCOE JIC assumed a network was in place. Since a network 
architecture was developed and not just an operational environment, the function 
establishing the network, provide connectivity, needed to be a top tier function. Another 
area of divergence with the NCOE JIC was the separation of information management 
functions from network management functions. The NCOE JIC combined the two 
capabilities underneath the overarching network management capability. It was believed 
that management of the network itself is a very different function than the management of 
information that is intended for the warfighter. 

5. roEFO 

Needs analysis was continued by constructing draft Integration Definition for 
Function Modeling (IDEFO) diagrams. The draft IDEFO diagrams were used to identify 
and analyze the functions that are performed by the system. This analysis helped identify 
shortcomings in the draft diagrams and make the necessary revisions to the architecture. 
The revised IDEFO diagrams show data flow, system control, functional flow, and 
transformation of inputs into outputs by the system. Additionally, the diagrams provided 
a reference architecture for analysis during alternatives generation. Overall, the IDEFO 
products are a coordinated set of diagrams that helped facilitate understanding using both 
graphical and natural language. 
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The IDEFO was started by building a system boundary diagram, A-1, to establish 
the boundary of the system in relation to external systems. The system boundary diagram 
shows how the ASW weapon systems, users (includes systems and platforms), ASW 
sensor systems, meteorological and oceanographic (METOC) systems, and the ASW 
threat interact with the system. After multiple iterations, inputs and outputs were made 
generic so that the system is adaptable to many different situations. For example, the 
system receives ASW weapons data from the ASW weapons systems; ASW sensor data 
from the ASW sensor systems; and user commands and user information requests from 
the users. Furthermore, the system returns ASW weapon tasking to the ASW weapons 
systems; ASW sensor tasking to the ASW sensor systems; and published or subscribed 
data back to the users. All of this is displayed in Figure 11. 
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Support Systems 


Figure 11. A-1 (External Systems) IDEFO Diagram 

This figure displays the A-1 diagram which displays the Joint ASW C4I Architecture relationships with the ASW weapon systems, ASW 
sensor systems, users, METOC, and the ASW threat. 
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ASW sensor data may include intelligence, reconnaissance, or surveillance data, 
or any other potential source that can generate data or information on a contact of 
interest. ASW weapons data may include action taken by the weapons or any other status 
of the weapon system. User commands may include requests for information or data, or 
operational tasking. ASW sensor tasking includes sensor queuing. Published and 
subscribed data may include ASW sensor data, ASW weapon data, fused data, or the 
COTP. 

Our group continued building the IDEFO diagrams by creating an AO which is a 
top-level functions diagram. The top-level functions diagram shows the internal data 
flow, system control, functional flow, and transformation of inputs into outputs. The top- 
level functions diagram is displayed in Figure 12. The additional detailed IDEFO 
diagrams can be found in Appendix E. 



Figure 12. IDEF AO Diagram 

This figure displays the top-level functions diagram which shows the internal data flow, system 
control, functional flow, and transformation of inputs into outputs. 
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Some of the important inputs and outputs are defined as follows: 

ASW Sensor Data - Raw or processed sensor data that is transmitted to the Joint ASW 
C4I Architecture by all of the ASW sensors in the network. This includes all devices that 
measure or detect real-world conditions, such as acoustic or electromagnetic sensors. 

This can also include sensor-to-sensor cueing which is transported through the 
architecture and sent to another sensor through ASW sensor tasking. 

ASW Sensor Tasking - Transports the ASW sensor task to the external sensors. 

ASW Sensor Tasks - The “Provide ASW Data and Information Management” function 
transmits the ASW sensor tasks to the “Transport ASW Information from End-to-End” 
function. Commands for the sensors that enable sensor resources to be dynamically 
focused on high priority sectors of the battlespace. This enables a scarce sensor resource 
to serve many customers, and helps ensure that the right mix of sensors are available at 
the right time. The operational benefit of sensor tasking is enhanced when sensors from 
multiple platforms simultaneously focus their energy on the same object. These are 
generated based on ASW sensor data or user commands. Sensor tasks can include sensor 
cueing, tracking, or battle damage assessment. 

ASW Weapon Data - Weapon data that is transmitted to the Joint ASW C4I 
Architecture by all of the ASW weapon assets in the network. This includes weapon 
status and engagement status for post engagement re-evaluation. 

ASW Weapon Tasking - Transports the ASW weapon task to the external weapons. 

ASW Weapon Tasks - The “Provide ASW Data and Information Management” function 
transmits the ASW weapon tasks to “Transport ASW Information from End-to-End” 
function. These are generated based on user commands. Weapon tasks can include 
weapon control orders, weapon assignment, or weapon and target pairing. 

Subscribable ASW Information - The “Provide ASW Data and Information 
Management” function transmits the subscribable ASW information to the “Transport 
ASW Information from End-to-End” function. The subscribable ASW information can 
range from sensor data to the COTP and is disseminated based on user subscriptions. 

User Commands - An instruction given by the user that needs to be transported to the 
appropriate external or internal asset. User commands can include cueing the sensors, 
target nomination, threat evaluation, and weapon assignment. 

User Information Requests - This is a request for specific information from the user. It 
can be returned to the user through published information or smart pull of information. 
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User Subscriptions - Users request to receive or obtain frequent updates on specific 
information. 

The definition for the rest of the inputs and outputs in the IDEFO AO can be found in 
Appendix E. 

6. Functional Flow Block Diagram 

The functional analysis was completed by constructing draft functional flow block 
diagrams, conducting an analysis, and building a revised functional flow block diagram. 
The Joint ASW C4I Architecture interacts with the three main functions of the kill chain: 
detect, control, and engage. However, the architecture is mainly centered on the control 
aspect of the kill chain. Through the application of network-centric principles, the 
architecture should be able to effectively shorten the kill chain through increased 
situational awareness, increased decision making velocity, and rapid dissemination of 
processed data that has been turned into actionable information. 

Figure 13 displays a subset of the revised enhanced functional flow block diagram 
and shows how published information reaches the user in the Joint ASW C4I 
Architecture. The enhanced functional flow block diagram begins when the ASW Sensor 
Systems detect a threat and passes the ASW Sensor Data to the Perform I n f ormation 
Operations function. The Perform Information Operations function assures that the data 
is coming from a valid source and passes it to the Transport ASW Information from End- 
to-End function for transport through the architecture. From there, it sends the ASW 
Sensor Data to the Provide ASW Data and Information Management function for storage, 
fusion, inclusion in the COTP, and dissemination. The Provide ASW Data and 
Information Management function then sends the publishable information back to the 
Transport ASW Information from End-to-End function for additional distribution. From 
there, the information is published to the users, and the users send their commands back. 
The Transport ASW Information from End-to-End function then sends ASW Sensor 
Tasking to the ASW Sensor System or ASW Weapon Tasking to ASW Weapons System. 
Appendix F includes the complete functional flow block diagram. 
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Figure 13. Enhanced Functional Flow Block Diagram 

This figure shows a subset of the enhanced functional flow block diagram which shows how the 
system publishes information. The figures shows how sensor data is passed through the 
architecture, how that information can be acted upon with user commands, and how ASW weapon 
tasking is sent back to the ASW weapon systems. 
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D. FUTURES ANALYSIS 

1. Purpose 

Futures Analysis is the fourth tool, in addition to Stakeholder Analysis, Threat 
Analysis, and Funetional Analysis, that was used to eomplete the Needs Analysis phase 
of the systems engineering proeess. The purpose of Futures Analysis is to make educated 
predictions with respect to the future operational environment; in this case the future 
environment that was addressed extends to the year 2020. This analysis is conducted to 
identify and discover critical requirements that will shape and define future development 
of the system, provide flexibility and robustness in the face of a changing environment, 
and to extend system life. Extreme care should be taken with regards to future 
predictions, the longer the time horizon the riskier the predictions. 

2. Process 

Figure 14 is a simplified depiction of the Futures Analysis process. A thorough 
Futures Analysis is a time consuming and a difficult undertaking as it depends on a large 
set of complex and inter-related activities [Technology Futures Analysis Methods 
Working Group, 2003]. This Future Analysis is a simplified process that takes as input 
the Primitive Need statement and performs a handful of activities, namely, review of 
technology trends. Joint Vision 2020 document, the Program Executive Office 
Command, Control, Communications, Computers and Intelligence Masterplan and 
information from Department of Defense and its agencies from relevant web sites. The 
output or the results are findings, recommendations, and insights which are combined 
with the results from other Needs Analysis tools to produce the Effective Needs 
statement. 
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Figure 14. Futures Process for ASW C4I Net-Centric Operations 

This figure shows the Futures Analysis step in the ASW C4I System Engineering process. The 
activities inside the process box are executed - serial, parallel, iterative and feedback to arrive at 
the output. 
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3. Results 

Figure 15 is an operational view of the future C4I Environment. 



Figure 15. 2020 Net-Centric Operational Environment 

This is a representation of a net-centric operational environment. This figure depicts real-time 
interaction enabled by the Joint ASW C4I Architecture between the air, surface, and subsurface 
components. 

In order to attain the Joint Vision 2020 goal of full spectrum dominance this 
requires a net-centric operational environment as outlined in the NCOE JIC and the JFC. 
The figure shows a globally connected force by land, air, surface, and subsurface. It 
includes manned and unmanned components out to the tactical edge. It is expected that 
ASW components will have enhanced communication capabilities. The Joint ASW C4I 
Architecture should include the capabilities to meet the needs for the warfighter to 
conduct distributed and power to the edge operations. The capability to enable ASW net- 
centric operations should also include the needs for the warfighter through a vetted 
process and stakeholder input. The future of planned systems and programs of record; 
through conducted research and analysis will include many of the capability 
requirements. The enhancement of legacy systems or retirement of legacy systems by 
replacement must be included in the scope of futures development. A major support 
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element of the any communications architecture must be a system that allows voice, data, 
information, and video to be transported. One such capability is the use of software 
defined radio and wideband network waveforms. The software defined radio capability 
enables many of those requirements for wireless security of communications, wideband 
waveforms, and common architecture a hardware package that is easily reconfigured 
simply by software to define the radio and encryption package. The capability provides 
bandwidth for data, voice, and video pushing power to the edge of the complete 
battlefield. A family of different hardware packages in air, land, sea, sub-surface, and 
space will support a wide range of applications in a net-centric operation environment. 
This net-centric operation environment will include single purpose terminals, line-of- 
sight communication links, beyond line-of-sight communication links, narrow band and 
wideband communications, transmitting voice, video, and data at high rates. Devices will 
have to range from handheld devices to multi-band, multi-mode, multi-channel radios 
supporting voice, video, and data communications on every conceivable platform [PEO 
C4I Masterplan, 2007]. 

It is also expected that technology will mature to support two-way submarine 
communication at speed and depth and the Joint ASW C4I Architecture must address 
this. Communication at speed and depth requires buoyant cable antenna technology, 
recoverable tethered fiber optic communications, and laser communications. These new 
communication buoys will support satellite communications and acoustic 
communications [PEO C4I Masterplan, 2007]. 

The Department of Defense has embarked on transforming its current stove-piped 
operational environment into a net-centric operational environment. A net-centric 
operational environment depends on the service-oriented architecture paradigm. The 
NCOE JIC defines service-oriented architecture with the following: 

The ability of networked users to manage and make available relevant, accurate 
information, transform it into knowledge, and act upon it with confidence. This 
provides access to newly discovered or recurring information in a useable format 
and facilitates collaboration, distributed decision-making, adaptive organizations, 
and a greater unity of effort via synchronization and integration of force elements 
to the lowest levels [NCOE JIC, 2005]. 

The Joint ASW C4I Architecture, indeed the entire DoD information technology 
portfolio, must align, support, and adapt to the service-oriented architecture to enable a 
true net-centric operational environment as envisioned in the NCOE JIC. 

E. EFFECTIVE NEED 

The following effective needs statement was defined based on the completion of 
the needs analysis: Key ASW stakeholders require a new standardized joint ASW- 
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specific C4I architecture for the 2020 target time frame. The proposed Joint ASW C4I 
Architecture needs to use open standards, common waveforms, and a common data 
schema. It needs to be consistent with DoD policy and processes and be vertically 
integrated with other DoD C4I systems. It will enhance the commander’s ability to 
execute the joint ASW mission in support of a Combatant Commander’s campaign 
objectives [NCOE JIC, 2005]. The purpose of the architecture is to guide development 
and to support engineering, force composition, and acquisition decisions. 
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III. VALUE SYSTEM DESIGN 


The value system design is the second step in the systems engineering process. The 
purpose of a value system, also called value hierarchy, is to refine the system 
requirements based on the effective need, to uncover conflicts in stakeholder preferences, 
to document stakeholders’ objectives, and to aid in evaluating and ranking design 
alternatives. The value system hierarchy also serves to improve communication among 
the team members and stakeholders, and it guides research and decision making. 

The value system design process is graphically depicted in Figure 16. The 
process began with input from the needs analysis step of the systems engineering process, 
namely, the effective needs statement, and the results of the stakeholder analysis, threat 
analysis, and functional analysis. The entire process was iterative; each lowest tiered 
function was assigned an objective and then the objective was validated against 
stakeholder requirements, the NCOE JIC, and the NCE JFC documents. The evaluation 
measures for each objective were also derived iteratively from review of the stakeholder 
needs, the NCOE JIC, and the NCE JFC. The principles that guided the selection of the 
objectives and evaluation measures are listed below. 

1. Clearly and unambiguously linked to stakeholder needs. 

2. Resolve conflicting evaluation measures based on stakeholder needs and 
values. 

3. Objectives which are independent and complete. 

4. Quantifiable objectives that will distinguish alternatives; use qualitative 
measures otherwise; all objectives must be either quantitatively or 
qualitatively expressed. 

5. Based on operations 

6. These are the stakeholders’ objectives and they make all value judgments. 

The value hierarchy design process was difficult and consumed much time. A 
number of measures of effectiveness for each lowest tiered function were proposed and 
then discarded. The discussions centered on meaning and interpretation of the value, 
which was the “best” value to choose and how easily it could be measured and modeled. 
The following summarizes this capstone project design team’s experience well, 
“developing a good set of measures of effectiveness is usually a harrowing business” 
[Feuchter, 2000]. 
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Figure 16. Value System Design Process 

This figure represents the value system design process. Its input is a fully decomposed functional 

hierarchy and the output is evaluation measures for each lowest tier function. 

A. VALUE HIERARCHY 

The value hierarchy for the Joint ASW C4I Architecture is depicted in Figure 17. 
The value hierarchy has two distinct branches, functional (System Performance) and non¬ 
functional (System Availability). Availability is a higher level measure which depends 
on a number of sub-measures such as reliability, supportability, producibility, and 
maintainability. Generally, there are more non-functional requirements to be measured 
but it was decided to use availability as it is derived from reliability and maintainability 
measures and is a good non-functional measure for the architecture. 

This value hierarchy was developed as part of the system engineering design 
process to aid in evaluating and ranking alternatives and then choosing the alternative 
that best meets the stakeholder requirements and values for the Joint ASW C4I 
Architecture. The first step in creating the value hierarchy was a functional and non¬ 
functional decomposition of the instantiation of NCOE JIC C4I architecture. The second 
step was to assign objectives to the lowest tier functions. The third step was to assign 
evaluation measures to each objective. 
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Figure 17. Value Hierarchy 

This is the complete ASW C4I functional and non-functional hierarchy. The top level functions are in light blue, the objectives are in dark blue, and the 
evaluation measures are the light yellow squares. 


61 




































































































































































































































B. EVALUATION MEASURES 

The evaluation measures are based on the feedback provided by the stakeholders. 
They are captured in “Stakeholder’s Consolidated Feedback” dated March 06, 2008 and 
can be found in Appendix C. In short, the stakeholders desire a net-centric operational 
environment. In other words, the stakeholders desire to have a timely common 
operational and tactical picture, low latency, high accuracy data fusion, human system 
integration, knowledge management, reduced human error, interoperability - joint and 
coalition, and actionable information whose net effect is a time reduction of the kill 
chain. 

The iterative value system design process yielded twenty functional evaluation 
measures, and four non-functional evaluation measures for a total of twenty-four 
evaluation measures. The large number of functional evaluation measures is indicative of 
the complexity of the Joint ASW C4I Architecture. As stated previously, these 
evaluation measures were based on stakeholder feedback before using them in the 
evaluation of alternatives. This step was necessary in order to make effective use of the 
evaluation process as a large number of evaluations make the scoring process 
cumbersome and complex. Appendix D contains the complete description of the 
evaluation measures. 

The survey data from stakeholders’ responses were merged together. Table 1 
summarizes the top ranked functions from stakeholder feedback plus one lower ranked 
function. Transmit ASW Information. The top requirement was almost unanimously the 
Provide ASW COTP function. Besides that, three other functions had a higher priority 
among the stakeholders and, therefore, they were worth measuring in order to compare 
alternatives later in the systems engineering process. These three functions are Fuse 
ASW Data, Interconnect Communication Nodes, and Enable Smart Pull and Push of 
Information. The Transmit ASW Information evaluation measure represents the end-to- 
end latency and throughput between source and sink of data - two nodes engaged in a 
transaction. This is not the “system” latency, throughput or performance. 
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Function 

Evaluation 

Measure 

Deflnition 

Rationale 

Provide ASW 
COTP (A.5.2) 

Percent of users 
with access to 

COTP 

The unit of measure 
is percent. The 
numerator 
represents the 
number of users 
with access to the 
COTP. The 
denominator 
represents the 
number of users. 

No threshold or 
objective values 
have been 
determined yet. 

It is a measure of 
situational 
awareness which 
promotes 

synchronization of 
action among strike 
group members in 
carrying out the 
commander’s 
intent. 

Fuse ASW Data 
(A.5.1) 

Minimize data 
fusion processing 
time 

The unit of measure 
is the time required 
to produce an 
output from the 

Fuse ASW Data 
function. No 
threshold or 
objective value has 
been determined 
yet. 

The lower the 
latency of fused 
data the more 
accurate the COTP. 

Interconnect 
Communication 
Nodes (A.1.1) 

Time to join 
network 

Minimize Network 
Join Time - Join 
Time is defined as 
the amount of time 
it takes for a node 
to advertise its 
presence, be 
authenticated and 
associated, and be 
capable of 
transmitting and 
receiving network 
data. Degree of 
connectivity is the 
number of 
connections. 

The ability to share 
common situational 
awareness data 
depends on the 
degree of 
connectivity. Fast 
and redundant 
network 
connectivity 
promotes 
robustness of 
communications. 
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Enable Smart Pull 
and Push of ASW 
Information 
(A.5.3.4) 

User response time 
to eritical 
information 

The measure is the 
response time to a 
user request or 
demand. The 
threshold is < 1 
second. The 
threshold value if 
from NCOE JIC. 

Smart push is the 
ability to gather 
information, 
process that 
information, and 
make decisions on 
who should receive 
it. Smart pull 
allows the war 
fighters to grab the 
information that is 
needed, regardless 
of where they are 
located. 

Transmit ASW 

Information 

(A.4.1) 

Total node to node 
latency 

Communication link 
data throughput 

Sum of data 
transmission 
latency and path 
latency for each 
hop between two 
nodes 

Throughput was 
calculated as 
Message size 
divided by latency 

Minimize network 
latency to improve 
response time 
Maximize 
throughput to 
improve COTP 
distribution, and 
reduce push/pull 
time 


Table 1. Top Ranked Functions 

This table summarizes the evaluation measures, their definitions, and the rationale for choosing 
them. 
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IV. ALTERNATIVES GENERATION 


A. GENERATION PROCESS 

Our alternatives generation process, illustrated in Figure 18, consisted of five 
separate actions: research, construction of a FY2020 Joint ASW C4I Architecture 
Baseline, functional gap analysis, stakeholder value hierarchy survey, and brainstorming 
of alternative solutions which were completed in series. The resulting alternative 
solutions conform to stakeholders needs, are functionally correct, and offer feasible 
solutions for further consideration and risk analysis. 



Figure 18. Alternatives Generation Process 

Five steps taken to obtain alternative solutions included researching activities, construction of a 
FY2020 Joint ASW C4I Architecture Baseline, a functional gap analysis, consolidation of the 
stakeholder gap analysis, and brainstorming activities relative to alternative solutions. 


The purpose of this study is to address shortfalls of the United States Navy’s 
ASW community’s current system fielding plan for the FY2020 Joint ASW C4I 
Architecture Baseline. To accomplish this, research was conducted to identify 
technology driven system capabilities, current and planned C4I technologies, consider 
strengths and weaknesses of network topologies, and the basics of today’s submarine 
communications problem. The Joint ASW C4I Architecture was constructed setting the 
timeframe at FY2020 because of research and acquisition time. A functional gap analysis 
was conducted by comparing research findings and FY2020 Joint ASW C4I Architecture 
Baseline capabilities with the system performance and system availability attributes 
identified earlier in this report. The findings of the Functional Gap Analysis were 
combined with the results of the Value Hierarchy Stakeholder Survey where the 
stakeholders identified by priority the functions that they rated as most important. The 
resultant list of functional gaps was then used to brainstorm possible alternative solutions. 
Areas of risk have been highlighted throughout this section and summarized at the end of 
this section to ensure ASW community awareness of cost, schedule, and performance 
issues that could alter the functional capabilities identified in the FY2020 Joint ASW C4I 
Architecture Baseline. Doctrine, Organization, Training, Materiel, Leadership and 
Education, Personnel, and Facilities (DOTMLPF) solutions offered in this report must be 
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interoperable with established C41 relative DoD programs of reeord and eommercially 
available communications network tools to most efficiently support ASW warfighter C4I 
requirements. Alternative solutions will be interoperable with joint service C4I network 
architectures in operational use beyond FY2020. It was assumed that areas of technology 
advancement including research and development projects currently underway or planned 
by DoD laboratories and agencies are being directed toward addressing the requirements 
of the United States Navy’s Fleet Top 10 C4I Requirements offered in Table 2 and will 
have enabled many of the end state goals of their project work for use in the FY2020 
Joint ASW C4I Architecture Baseline. This table was not included in the requirements 
section because it was derived during research and was not part of the stakeholders’ 
original requirements or intentions. 
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C4I Requirement 

Description 

1. Coalition and 

Multinational 

C4 Interoperability 

United States Navy’s vision of 1,000 ship Navy is dependent 
upon the ability to share information and interoperate in a 
multinational environment. 

2. Reliable Satellite 
Communication 

Reliable satellite communications is a major Fleet priority. 

3. Data Throughput 

Data throughput is the ultimate measure of connectivity to 
forward deployed units. It is increasingly limited by 
applications which demand higher bandwidth during warfighter 
reach back activities. 

4. Computer Network 

Defense 

Defense of the networks is critical to their use as weapons 
systems. Continued focus on improved computer network 
defense is validated by the fleet. 

5. Common Operational 

Picture and Maritime 

Domain Awareness 

United States Navy’s use of Maritime COP has expanded to 
include not only traditional blue water force-on-force scenarios 
but also the MDA mission. 

6. Real-Time Collaboration 

Real-time collaboration is critical to the warfighting 
commander. Tools and technologies bring instantaneous 
transfer to vital information and decisions that allow forces 
increased battle space flexibility. 

7. Standards Based on 
Information Technology 
Service Management 

Best Practices 

C4 environment is in critical need of standardized processes, 
doctrine, technology implementation, and metrics. Information 
technology service management based on the information 
technology infrastructure library framework offers a coherent, 
adaptable, and flexible approach to Navy C4 deployment, 
warfighting use, and life cycle sustainment. 

8. Streamlined Administrative 
C4 Processes 

Administrative processes directly affect proper management of 
C4I environment while fully engaged in warfighting planning 
and operations. Use of joint processes and documentation will 
reduce current administrative burden. 

9. C4I Training 

Increased deployment of complex technology and lack of 
training curriculum responsiveness led to ineffective C4I system 
maintenance. 

10. Warfighting Network 
Sustainment and Life 

Cycle Management 

Holistic approach to C4 Networked environment is absolutely 
vital. Separation by region by area of operations is an unrealistic 
means to ensure reliable and redundant global communications. 
Result is under equipped and under funded end-to-end network 
nodes adversely affecting warfighting capacity of entire netted 
force. 


Table 2. Fleet Top 10 C4I Requirements - 2007 

These requirements provide the operational fleet perspective on ten DOTMLPF areas of concern 
needing the attention of the ASW community, the United States Navy and DoD to resolve [PEO 
C4I Masterplan, 2007: 19-20]. 

1. Conduct Research 

Our investigation focused on ASW C4I applications and systems relating to the 
construction of a FY2020 Joint ASW C4I Architecture Baseline. The primary research 
objective was to definitively account for systems planned to be in operational use by the 
United States Navy and contributing to the service and joint wide C4I network 
architectures in FY2020. Research findings were categorized into three specific areas 
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impacting future C4I networking architectures and supporting applications: program of 
record planned ehanges, network topologies, and communicating with submarines. 

a. Program of Record Planned Changes 

The United States Navy is currently transitioning from legaey systems that 
do not seamlessly interfaee or distribute information to the end users. Current aequisition 
strategies appear direeted at reducing expense by looking at all major programs and new 
starts and deliberating the value of new expensive ships and aireraft against the use of 
older ships and planes that have solid track records of performance and come with 
existing production line capabilities. The United States Navy’s ASW eommunity will 
need to embrace not only fellow United States Navy communications networks and 
techniques but smartly carry out business plans to identify shared funding opportunities 
with other United States Navy and joint serviee program offices working similar 
communieations initiatives to offset system testing and development, proeurement, 
operations, and maintenance costs. 

We found that functional capabilities existed or were planned offering 
near and mid term solutions out through the latest program objective memorandum eycle 
from FY2010 to FY2015. Two key research documents proved invaluable in validating 
ongoing programs of reeord, projects, planned test and evaluation events, and design 
studies contributing to the identifieation of systems and subsystems for the FY2020 Joint 
ASW C4I Arehitecture Baseline. First, the C4I Masterplan is 

designed to be the single reference doeument that program managers, 
resource sponsors, and warfighters ean go to get an understanding of what 
transformation is required to meet modem warfare needs, what is planned and 
budgeted for, known shortfalls, future budgeted modifieations to meet those 
shortfalls, baseline architeetures, future arehiteetures, and reeommendations for 
modernization initiatives [PEO C4I Masterplan, 2007: iv]. 

This over arehing, living document ensures all umbrella C4I related 
programs of record, supported by several major design studies, lead to a network 
centrie naval foree. Four speeific areas needing attention from the ASW 
community - communications, networks, eommon computing environment and 
common services, and application services are further detailed by the 
Masterplan/Reference Model/ Portfolio/Entitlements/Programs of Reeord Matrix 
[PEO C4I Masterplan, 2007: 32]. 

Second, the Communications at Speed and Depth and Optical Laser 
Communications Status PEO C4I briefing recommended by the stakeholder community 
gave deseriptive insight into the United States Navy submarine community’s 
communications speed and depth family of systems including scheduling, and 
performance characteristies expected of current and planned C4I related programs and 
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projects [Reddish and Lovem, 2007]. The C4I Masterplan represents the United States 
Navy’s plan to transform from stove-piped architectural systems into a C41 network¬ 
centric architecture and is a comprehensive account of the condition and plans for 
improvement of the United States Navy’s C4I network architecture. Both documents 
provided specific C4I network related technological advancements that seek to close 
functional gaps identified by stakeholders. 

The ever growing global marketplace allows unprecedented access to the 
latest off the shelf communications tools making it much more difficult for United States 
forces to stay ahead of adversaries in areas such as subsurface sensing, communication 
techniques, lethal and non-lethal weapons, and damage assessment assets. To counter 
improved adversarial technologies research suggests the ASW community fiilly 
recognize the need for a systems engineered C4I network solution using identified 
strengths of joint service capabilities coupled with foreign coalition forces C4I 
operational capabilities to identify complete best of breed communications toolsets. The 
following excerpt from the PEO-C4I Masterplan highlights the need and requirement for 
the ASW community to be fiilly engaged in communications programs planned to meet 
the DoD Net-Centric goals. 

As part of the joint force all services, including the ASW community, are 
required to meet the interoperability requirements identified by several large 
ACAT I communications programs meeting DoD’s Net Centric goals. It is 
imperative for the ASW community to gain the necessary technologies and 
capabilities to interoperate with these programs interconnecting into the global 
network these C4I programs of record provide [PEO C4I Masterplan, 2007: 20]. 

DoD sponsored design studies provided important information identifying the best path 
to meet future requirements and those focused on elimination of stove-piped legacy 
systems. The assumption was made that the planned program of record systems listed in 
the PEO-C4I Masterplan will be funded and implemented and that the current design 
studies listed in the PEO-C4I Masterplan will be funded by one or more program offices. 
Also, it was assumed that the recommendations of these current design studies will be 
funded and implemented. The following abbreviated design study summaries are taken 
from the C4 Masterplan pages 23 to 27 and provide rationale for their inclusion within 
the FY2020 Joint ASW C4I Architecture Baseline [PEO C4I Masterplan, 2007: 23-27]: 

Global Information Grid Joint Tactical Edge Networks (JTEN) 

The JTEN is an Office of the Secretary of Defense initiative to 
improve joint connectivity in the battlespace. It proposed developing a set 
of joint Tactical Edge Networks as a means to address and resolve 
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shortfalls in the current Global Information Grid architecture, over the 
next several years. GIG JTEN is a joint effort that will identify needed 
capabilities to support multi-mission warfare requirements into and 
beyond the 2015 timeframe. It is focused on the tactical edge first and 
will build outward using a spiral engineering approach. JTEN capability 
benefits include: enhanced applications interoperability, improved 
security, more effective management of the network’s limited resources, 
more extensive collaboration among units, smarter publish-subscribe 
services, a shorter technology development cycle, enhanced 
interoperability among the GIG components, and improved platform 
connectivity. Functional areas include: architecture and concept of 
operations, routing and network dynamics, tactical wireless connectivity, 
mission applications and JTEN services, network management and 
operations, and information assurance. 

Joint Track Manager (JTM) 

The vision of Joint Track Manager is to provide common merged 
track data across the tactical, operational, and strategic domains. JTM will 
use all available resources to provide capabilities maximizing the accuracy 
and controlled management of persistent situational awareness data. 

Track data will be distributable to all levels of command, coalition 
partners, and civil agencies using profiles, filters, and security services to 
manage the level of detail shared. The workload and required skill sets 
required to manage and maintain the track data will be reduced through 
maximized use of automation. 

Joint Tactical Edge Network and Gateways (J-TENG) 

The warfighting objective of Joint Tactical Edge Network and 
Gateways is to provide a network-centric operating environment for 
improved communications and collaboration between warfighters, manned 
and unmanned platforms, and network-enabled joint fires at the forward, 
or “tactical edge’’ of the battlespace. The bottom line is to extend Global 
Information Grid capabilities to the tactical edge. J-TENG capabilities 
will support a full range of military operations for Combatant Commander 
missions stated in the Unified Command Plan (deterrence, execution, 
planning, and force protection). Characteristics of the operating 
environment at the tactical edge include a modular, dispersed, on-the- 
move force, operating increasingly in urban environ m ents and other 
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complex terrain ineluding maritime and littoral operations. It is assumed 
that forees will include joint and coalition forces; and for eivil support and 
humanitarian relief missions, will include federal, state, loeal, tribal 
agencies, and non-governmental ageneies in addition to military forees. 

Network Rationalization (NR) Initiative 

This initiative found that legaey network proliferation afloat 
impedes affordable, efficient C4I and taetieal edge network 
implementation that supports advanced information teehnology, 
information assuranee, network capabilities, forces duplication of 
acquisition, DOTMLPF operations, and sustainment eosts. Two main 
thrusts were proposed. First, to provide an affordable, effective alternative 
for legacy programs and systems afloat - as currently programmed by 
Chief of Naval Operations (OPNAV) N6 and PEO C4I, the Consolidated 
Afloat Networks and Enterprise Serviees is reeommended. Seeond, the 
United States Navy leadership needs to embrace the “Transformation by 
Redueed Total Ownership Costs” DoD initiative within the enterprise 
naval network environment. 

Serial Circuit Transition Afloat 

This study was eommissioned to determine the number of serial 
conneetions that are still in use within the fleet. As the Navy moves 
towards its goal of net-centrieity, it is vital to seek elimination of older non 
net-eentrie teehnologies. The Serial Cireuit Transition Afloat study is 
designed to identify eireuit loeations, resource owner, understand the 
mission they are designed for, and evaluate the ability of these cireuits to 
transition to an IP conneetion, the plan for transition, and what resources 
will be required. The transition to IP serves two purposes: to eontinue 
with migration to an all IP infrastructure and to assist in the effieient use 
of bandwidth on and off the ship. 

In addition to DoD C4I programs of reeord and design studies, the PEO- 
C4I Masterplan’s planned C4I portfolio strategies beyond the FY2012 timeframe was 
taken into aceount as identified in Table 3 for use in speeifying systems and refinement 
of funetional capability gaps of the FY2020 Joint ASW C4I Architecture Baseline. 
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Portfolio 

Probable Solution Sets 

Expected 

Fielding 

FY 

Wideband Satellite 

Communications 

1. Terminal integration using United States Navy’s 
Multiband Terminal, and launch of first 
Transformational Satellite. Current AN/WSC- 
6(V) super high frequency terminal functionality 
will be incorporated within Navy Multi-Band 
Terminal (NMT) to provide single terminal, when 
paired with the appropriate aperture that will 
provide wideband (Ka, X-Band) and protected 
(Q/Ka) satellite communications. NMT terminal 
will be upgraded to interoperate with 
Transformation Satellite System [PEO C4I 
Masterplan, 2007: 45]. 

2. Advanced High Data Rate (HDR) is next- 
generation multi-band antenna for wideband and 
protected submarine communications. Potential 
use of phased array technology providing two-way 
wideband capacity for K/Ka/Q satellite 
communications including Extremely High 
Frequency (EHF) Medium Data Rate (MDR), 
Advanced EHF, Wideband Gapfiller System, 
GlobalHawk, Joint Surveillance and Target Attack 
Radar System (JSTARS), and emerging military 
and commercial satellite systems. Advanced High 
Data Rate (AdvHDR) upgrades coincide with 

NMT implementation and fielding of Automated 
Digital Network System (ADNS) Increment III. It 
will provide wideband and protected 
communications to submarines, and multi-homed 
radio frequency for IP suite communications [PEO 
C4I Masterplan, 2007: 45]. 

2016 

2016 
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Portfolio 

Probable Solution Sets 

Expected 

Fielding 

FY 

Protected Satellite 

1. NMT protected systems deployed as 
replacement for Navy EHF Satellite Program 

2012 

Communications 

(NESP) terminals and primary military satellite 
communications terminal for Carrier Vessel 

Nuclear (CVN), Landing Helicopter Dock (LHD), 
Landing Helicopter Assault (LHA), Guided 

Missile Cruiser (CG), Guided Missile Destroyer 
(DDG), Landing Ship Dock (LSD), Landing 
Platform Dock (LPD), and Submarines [PEG C4I 
Masterplan, 2007: 47]. 

2. NMT wideband upgrade will begin in 4QFY12. 
Transformational Satellite Communications 

System (TSAT) compatible upgrade to NMT to be 
deployed to support the TSAT constellation, but 
no fielding schedule currently exists [PEG C4I 
Masterplan, 2007: 47]. 

TBD 

Broadcast 

Information Screening and Delivery Sub-System 
(ISDS) Medium Data Rate Channel Access 

Protocol (MCAP) will be upgraded for ADNS INC 
III for submarines, to include IP version 6 
capabilities, QoS and Ciphtertext Core. The 
Performance Enhancing Proxy, which is 
incorporated into the existing MCAP to efficiently 
utilize the 32 Kbps forward channel, will be 
extracted and incorporated in the ADNS INC III 
Plaintext segment, because it cannot operate in an 
encrypted environment [PEG C4I Masterplan, 

2007: 51]. 

2012 
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Portfolio 

Probable Solution Sets 

Expected 

Fielding 

FY 

Tactical 

Communications 

Joint Tactical Radio System replaces current high 
frequency, very high frequency, ultra high 
frequency, and Digital Wideband Transmission 
System (DWTS) systems. Joint Tactical Radio 
(JTRS) will attain Joint, Federal Agencies and 
Public Safety, Combined, and Allied and Coalition 
interoperability and performance requirements. 
Following attributes: software-reprogrammable, 
multi-band and multi-mode capable, mobile ad- 
hoc network capable, simultaneous voice, data, 
and video communications, several current legacy 
waveforms used by military and civilian agencies, 
can incorporate new waveforms as developed, 
scalable in terms of form, fit, and cost to meet 
specific user operational needs, open system 
architecture enabling technology insertion through 
evolutionary acquisition or Preplanned Product 
Improvement, high data throughput rates per 
channel, incremental channel expansion to 
increase network capacity, high levels of 
reliability, availability, and maintainability, and 
commercial support service compatible [PEO C4I 
Masterplan, 2007: 69-70]. 

2012 

Terrestrial Transport 
and Backhaul 

1. Navy shore wide area network Terrestrial 
Transport architecture removes all legacy circuits, 
Time Division Multiplexing (TDM) multiplexers 
no longer deployed on tactical platforms, all 
communications over IP, core will have 
successfully transitioned to cipher text (CT) 
routing, and connectivity between radio frequency 
termination points and IP services will be via the 
Defense Information System Network (DISN) 

Core [PEO C4I Masterplan, 2007: 82]. 

2012 


2. United States Navy’s High Speed Global Ring 
(HSGR) overlay on DISN Core for legacy services 
no longer needed, HSGR and teleport backhaul 
circuits will be completely integrated into the 

DISN Core providing dynamic bandwidth 
allocation and dynamic IP version 6 CT routing 
[PEO C4I Masterplan, 2007: 82]. 

2016 


74 




Portfolio 

Probable Solution Sets 

Expected 

Fielding 

FY 


3. Transformational Communications (TC) will be 
the major forcing function [PEO C4I Masterplan, 
2007: 83], 

4. Transformational Satellite Communications 
System launches. Full Operational Capability 
(FOC) consists of five satellite constellations in 
FY19. TSAT shore ground component at 
locations to be determined, most likely at a 
combination of Teleport and TSAT GIG Border 
Element (TGBE) sites [PEO C4I Masterplan, 

2007: 83], 

5. The Regional Network Operations and Security 
Centers (RNOSCs) are major shore tactical 

2012 


communications nodes and provide an opportunity 
for further tactical application hosting center 
consolidation. If Navy migrates completely to 
Teleports significant cost avoidance will be 
realized by allowing further site consolidation and 
legacy systems disinvestments [PEO C4I 
Masterplan, 2007: 83]. 

6. Submarine Operating Authority Wide Area 
Network (SUBOPAUTHWAN) will also 
transition to the DISN Core, and Submarines and 
Broadcast Control Authorities (BCAs) will 

2013 


transition to ADNS INC III and a CT Core. Navy 
will be utilizing the IP solution fielded by the 
Teleport Program Office (TPO) under the Teleport 
Gen III Phase. All Navy communications and 
network services will be managed and controlled 
in near real-time by the RNOSCs, which will 
provide situational awareness and common 
operational picture information to Global Network 

2015 


Operations and Security Centers (GNOSC) and 

Joint Task Force (JTF) - Global Network 
Operations (GNO) [PEO C4I Masterplan, 2007: 

83]. 

7. Teleport Gen III FOC. Assume all Navy and 
Joint services have migrated to IP. Most services 
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will be High Assurance Internet Protocol 

Encryptor (HAIPE) encrypted and transported 
over the DISN Black Core. Unencrypted 
Unclassified services can still use the DISN 
Unclassified Core, as well as internet protocol 
video and voice services that are not HAIPE 
encrypted [PEO C4I Masterplan, 2007: 83], 

8. If DoD Teleports are configured with 
appropriate security devices and software 
applications (firewalls. High Assurance Internet 
Protocol Encryptor, Transmission Security 
(TRANSEC), and required routers), direct inter 
and intra-theater internet protocol connectivity can 
be achieved among Services via Virtual Routing 
and Forwarding (VRF) or similar technology that 
supports multi-exit domain connections for direct 
cross connect between and among the service’s 
net-centric internet protocol systems. A proposed 
FY13-FY15 Navy specific multi-exit domain 
future architecture builds upon ADNS INC III and 
the Tactical Switching (TSw) Navy Shore Tactical 
Architecture, to allow for implementation of a 

Navy internet protocol network solution that will 
seamlessly interface with the mature DISN Core 
for DISN services, other Navy users, and other 
military services, directly at the Teleports [PEO 

C4I Masterplan, 2007: 84]. 


Network Core 

“Relevant information for this area will be 

provided when planned upgrades are solidified 
[PEO C4I Masterplan, 2007: 93]. 

TBD 
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Shore Telephony 

Continued migration to Voice Over Internet 
Protocol (VoIP) and deployment of enhanced 
services to concentrations of high value end users. 
Value added services will include unified 
communications, web conferencing and 
collaboration. A consistent upgrade plan will be 
necessary to maintain current Defense Switched 
Network (DSN) and DISN interoperability and 
security [PEO C4I Masterplan, 2007: 113]. 

Due to funding constraints, continued operation of 
TDM “last mile” telephone service on base via 
legacy infrastructure will continue to be supported 
well into the future [PEO C4I Masterplan, 2007: 
114]. 

2012 

Shore Network 

Management 

1. TSw Network Management System (NMS) 
Increment III fully deployed for Navy Enterprise 
Network Operations to provide near real-time and 
real-time networks and communications 
situational awareness information to Navy 
Component Commanders and JTF-GNO for global 
operations of the GIG [PEO C4I Masterplan, 

2007: 119]. 

2. Operational and network management interfaces 
with Navy afloat networks, GIG, and Joint 
Communities completely fielded [PEO C4I 
Masterplan, 2007: 119]. 

2012 

2013 

Afloat Network and 
Systems 

Management 

CANES System Management capabilities fielded 
in spirals throughout the increments of CANES. 

2nd and 3rd increments scheduled to be fielded 
after FY12 [PEO C4I Masterplan, 2007: 123]. 

2012 
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Communications 

Circuit Management 

1. Navy shore communications infrastructure 
completely transitioned to internet protocol-based 
networks. United States Navy’s serial switching 
infrastructure replaced by internet protocol routers 
and switches [PEO C4I Masterplan, 2007: 128], 

2012 


2. High Speed Global Ring eliminated or provides 
edge access to DISN Core network; and 

Automated Network Control Center (ANCC), 
Automated Technical Control (ATC) switches 
replaced with an internet protocol, Asynchronous 
Transfer Mode (ATM), Multi-Protocol Label 
Switching (MPLS) control plane switching, and 
routing capability. For all non-Navy agencies and 
groups including Joint and other nations’ militaries 
which may still employ serial communications in 
this timeframe, technology will be left in place to 
accommodate requirements on an as needed basis 
[PEO C4I Masterplan, 2007: 128]. 


Network Operating 
Systems 

Specific details of each component of planned 
configuration are currently under development. 

The functionality of each component was briefly 
described in the section above [PEO C4I 
Masterplan, 2007: 135]. 

TBD 

Computer Network 
Defense 

No planning information available [PEO C4I 
Masterplan, 2007: 143]. 

TBD 
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Electronic Key 
Management System 
and Key 

Management 

Infrastructure 

Key Management Infrastructure (KMI) Capability 
Increment 3 will be realized and be a major pillar 
of the GIG infrastructure. It will provide a unified, 
net-centric infrastructure to provide integrated, 
consolidated and automated capabilities for 
ordering, generating, distributing, and monitoring 
status of all cryptographic products. Products will 
include Key, crypto software and other End 

Crypto Unit (ECU) management data. Product 
distribution to User nodes, and Over the Net 

Keying (OTNK) [PEO C4I Masterplan, 2007: 

150]. 

KMI focus will be on wrapped product distribution 
and operations over the network for all KMI users 
and managers. It will also provide transparency 
and mobility (operate from any client) and will 
have a web based user interface. It will provide 
direct Product Distribution to Net enabled ECUs, 
Over the Net Keying, Role and Rule based access 
control, Type 1 public key infrastructure (PKI) for 
managers and ECUs, and a modular architecture 
[PEO C4I Masterplan, 2007: 150]. 

2012 
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Fielding 
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Public Key 
Infrastructure 

Implement Ron Rivest, Adi Shamir, and Leonard 
Adleman (RSA) 2048 when testing demonstrates 
performance is satisfactory across all domains. 
Following this, it will transition to Suite B 
algorithms (Elliptic Curve Cryptography (ECC) 
and Secure Hash Algorithm 256 (SHA-256)) when 
systems and applications ubiquitously support 

ECC & SHA-256 [PEO C4I Masterplan, 2007: 

155]. 

2012 


Evolving status of afloat infrastructures and 
operating systems will drive the implementation of 
the next generation of PKI, which will include 
elliptic curve cryptography and stronger hashing 
algorithms in support of confidentiality, integrity, 
and non-repudiation [PEO C4I Masterplan, 2007: 
155]. 



Table 3. C4I Masterplan Identified Planned Upgrades Beyond FY12 

PEO C4I offers a plan of attacking the Joint ASW C4I Architecture demands for improvement in 
areas significantly impacting the quantity and quality of data throughput to operational war 
fighters [PEO C4I Masterplan, 2007: 45-155], 

b. Network Topologies 

The selection of the best wide area network topology can lend powerful 
capabilities to the Joint ASW C4I Architecture’s maritime operations. One of the key 
objectives is to select a wide area network topology that will improve the throughput of 
time sensitive data from end user to end user between communication nodes without the 
loss of data. Equally important is a self-healing network topology that will permit the 
loss of one or more nodes while having limited or no impact on the interoperability of the 
remaining nodes on the network. Network topologies must ensure maximum operational 
availability for the overall network providing backups and workarounds to operationally 
control system down time for maintenance or repair. The network must remain 
operational through the duration of an ASW mission to be most effective for the ASW 
community users. Communications and network services between operational nodes 
must be available at all times to provide uninterrupted, tactically relevant service to the 
end user at each operational node. Mesh, star, partial mesh, and tiered wide area network 
topologies provide fleet communicators with differing levels of connectivity opportunity 
and, more importantly to this capstone project, the speed of receiving real time targeting 
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data. The FY2020 Joint ASW C4I Architecture Baseline will take advantage of manual 
and automatic network topology configuration controls to establish the most effective 
communications support for its ASW warfighters and decision makers. 

Network configuration is preplanned in most operational scenarios to 
provide the necessary bandwidth, frequency spectrum control, and robust securities for 
friendly forces. “A physical topology or the pattern of the nodes on a network depicts a 
network in broad scope. It does not specify device types, connectivity methods or 
addressing schemes for the network” [Dean, 2006: 286]. The ASW forces identified in 
the FY2020 Joint ASW C4I Architecture Baseline will have multiple tools to 
communicate in several wide area network topologies including mesh, star, partial mesh, 
and tiered as constrained or demanded by operational influences. The current 
communication systems in place today and the ones planned to be in place in the year 
2020 have the ability to be reconfigured on the fly to support variations in missions. 
United States Navy communications experts will determine how to configure the 
available communication systems on a mission by mission basis to provide the most 
efficient and robust network to support the specific mission operating environment. The 
alternatives that are presented later in this section will address improvements to the 
throughput and recommend the best wide area network topology best suited for collecting 
and fusing sensor data and distributing the COTP to the end users. 

Star wide area network topologies. Figure 19, are characterized by a 
central transmit and receive site which connects directly to individual nodes around it. 
These nodes do not connect to each other without first going through a central 
interconnection point. These are viewed as excellent point-to-point command and control 
networks such as takeoff and landing communication to permit the interconnection point 
to control its flight deck without overburdening its nodes with unnecessary data. It offers 
superb security of information opportunity between edge performers like a submarine and 
specifically identified operational headquarters. If a single node is designated to function 
as the central hub for collecting and fusing sensor data and generating and distributing the 
COTP, this configuration can be considered operating in a star topology using line-of- 
sight and beyond line-of-sight communication systems for connectivity. Figure 19 
depicts a notional star network topology for the Joint ASW C4I Architecture Baseline. 
The blue lines in Figure 19 represent line-of-sight communication links and the red lines 
represent satellite communication links. The central hub for this topology is the CVN 
Aircraft Carrier. The shore nodes represented by the satellite dish require either a 
satellite or aircraft relay to communication with the central hub. One of the drawbacks of 
this topology is the lack of the capability for each node to communicate directly with 
each other. 


81 




Figure 19. Notional Star Network Topology Based on Line-Of-Sight and 
Beyond Line-Of-Sight Communication Systems 

This figure shows a notional star network topology. The blue lines represent line-of-sight 
communication links and the red lines represent satellite communication links. The central hub 
for this topology is the aircraft carrier. Communications between the central hub and shore nodes 
require a relay through either a satellite or aircraft relay. 

Mesh networks allow node-to-node connectivity streamlining the receipt 
of time sensitive situational awareness information offering all nodes on this type of wide 
area network topology nearly real time access of a complete common operational picture. 
Efficient node based sensor information sharing is key to establishing and maintaining 
force wide awareness and reaction time. Shipboard, aircraft and shore based nodes have 
the ability to connect to each other over line-of-sight communication systems to form a 
mesh or partial mesh network connectivity between nodes. Figure 20 illustrates a 
notional partial mesh configuration that can be established between nodes using existing 
line-of-sight communication systems. The blue lines represent line-of-sight 
communication links. One of the primary drawbacks of this configuration is the 
requirement to implement and maintain multiple communication links for each node. 
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Tiered networks eombine the above topologies to take advantage of 
intereonneetion node to intereonneetion node reaeh baek beyond line-of-sight eapabilities 
to exehange data resulting in a strategie eommon operational pieture while eaeh 
individual node is freely gathering and exehanging data with eaeh other with or without 
the help of the intereonneetion node. Inereased battlespaee awareness is expeeted using 
this topology and the opportunity to eontrol regional information flow as neeessary to 
limit bandwidth overuse. Figure 21 illustrates a notional tiered network eonfiguration 
that ean be established between nodes using line-of-sight and beyond line-of-sight 
eommunieation systems. 


Figure 20. Notional Partial Mesh Network Topology Based on Line-Of-Sight 
Communication Systems 


This figure shows a notional partial mesh configuration for the Joint ASW C4I Architecture 
Baseline. The blue lines represent line-of-sight communication links. Note that the submarine 
node is required to be on the surface or at periscope depth in order to be part of the network 
topology. 
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Figure 21. Notional Tiered Network Topology Based on Line-Of-Sight 
Communication Systems 

This figure shows a notional tiered network configuration for the Joint ASW C4I Architecture 
Baseline. Blue lines represent line of sight communication paths and red lines represent satellite 
communication paths. 

The Joint ASW C4I Architecture Baseline can be configured in any of the 
three previously described network topologies shown in Figure 19, Figure 20, and Figure 
21 using the year 2020 planned systems outlined in the PEO-C4I Masterplan. The 
preferred topology is best described as a tiered wide area network topology illustrated in 
Figure 21 because the operators can make use of all communication links in both a star 
and partial mesh network topology as necessary to help maintain operational efficiencies. 

c. Communicating with Submarines 

To understand submarine communication strengths and weaknesses it was 
necessary to baseline today’s submarine C4I systems. Communication capabilities of the 
Virginia Class (SSN-774) and Los Angeles Class (SSN-688) submarines used in the 
FY2020 Joint ASW C4I Architecture Baseline begin with the Common Submarine Radio 
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Room (CSRR). The following is from the PEO-C4I Masterplan that describes the 
components and systems on a submarine that are used to conduct ASW functions. 

The components for all CSRR class submarines are the same but 
the number of antenna, transceivers, terminals and network components 
changes by class of submarine. These differences are driven primarily by 
the missions of each class of submarine as designed and based on sail and 
rack space. Radio frequency communications consist of antennas, radio 
frequency distribution, transceivers, terminals and crypto. Radio 
frequency communications are routed to either a tactical voice switch or 
logger for voice, or to the Automated Digital Network System Internet 
Protocol router for data. There is a direct data connection to the combat 
system for the Tomahawk Strike Network. The Command and 
Monitoring system allows for the monitoring, establishment and 
breakdown of all the radio room circuits and components. Automated 
Digital Network System distributes data to the different security enclaves 
including unclassified, top secret, and special compartmented information 
via inline network encryptions and directly to the Secret Submarine Local 
Area Network. Each enclave provides messaging capability, tactical 
applications via GCCS, chat and web service. The Time and Frequency 
Distribution System and NAVSSI distribute timing and GPS signals to all 
components in the radio room and combat systems. The SUBLAN is 
connected to the submarine Tactical Local Area Network (TACLAN) via 
a High Assurance Guard. Tactical Local Area Network is a period 
processing LAN that can operate at security classifications from secret to 
SCI, depending on the submarine’s mission. Tactical Local Area Network 
includes internet protocol services for all forward electronics systems on 
the submarine, including SONAR, fire control, electronic surveillance 
measure, navigation, RADAR, imaging and others [PEO C4I Masterplan, 

2007: 246]. 

Our stakeholder community has shown strong interest in technologies that 
will improve upon current communications techniques based on the PEO C4I 
“Communications at Speed and Depth and Optical Laser Communications Status” 
briefing and additional data exchanges with individual stakeholders including March 
2008 email exchange with Mr. Dave Cepek, N872A [Cepek, 2008]. Today’s technology 
projects addressing CSD demands of the Joint ASW C4I Architecture range from moored 
acoustic buoys to submarine tethered near-surface antennas to expendable acoustic-radio 
frequency surface buoys. All seek to bridge the interconnection gap at the air-sea 
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interface while allowing the submarine to remain at depth. Solving the interconnect 
issues is only part of the problem for two way communications. A critically important 
concern is the quality of the information being communicated. Today extremely high 
frequency wideband radio frequency communications are limited to submarines at 
periscope depth with raised antenna masts which are not submerged. To bridge the air- 
sea interface gap, future relay systems will need to account for data capacity differences 
and establish efficient means for transmission of time sensitive data to and from 
submarines. This communication includes blue force tracking which indicates a friendly 
boat’s course, speed, and depth; exchange of time sensitive intelligence, surveillance, and 
reconnaissance (ISR) or target data; and all other communications needed to conduct 
ASW operations in deep ocean or littoral areas around the world. 

2. Construct Joint ASW C4I Architecture Baseline 

A decision was made to use an aircraft carrier strike group to develop the baseline 
for the Joint ASW C4I Architecture Baseline. The aircraft carrier strike group in 
conjunction with the shore facilities, coalition partners, and other service components 
such as Air Force, Army, Marine Corp, and Coast Guard were used to develop the Joint 
ASW C4I Architecture Baseline. This baseline was developed in order to perform a 
decomposition of the functional architecture into the physical components or systems that 
currently perform Joint ASW C4I functions. The decomposition of the functional 
architecture into a physical architecture included existing and planned systems up to the 
FY2020 timeframe. We first identified a baseline using year 2008 systems for each node 
in the aircraft carrier strike group and conducted research for each system to identify 
which systems performed the functions identified in our ASW functional architecture. 
Later during the systems engineering process, it was decided to move the Joint ASW C4I 
Architecture Baseline to the year 2020. At this point in the systems engineering process, 
further research was conducted to determine the physical architecture that will meet the 
ASW C4I functional architecture in the year 2020. In order to determine a physical 
architecture for the FY2020 timeframe, it became necessary to determine the system that 
are planned to be funded and implemented by year 2020. Since the architecture is a C4I- 
based architecture, research led us to the plans of the PEO-C4I. Figure 22 depicts the top 
level results of the previously described analysis. 

The aircraft carrier strike group baseline depicted in Figure 22 identifies 
communication links between the various nodes or blue force platforms within the strike 
group used to perform the ASW mission. Each platform is identified by specific class or 
generic title and represented in the drawing by circles. The satellite icons, located at the 
top of this diagram are representative of more than one satellite constellation. FY2020 
satellite constellations are envisioned to consist of both military and commercial satellite 
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systems. These satellite systems eonsist of Mobile User Objective System (MUOS), 
Transformational Satellite System (TSAT), Ultra-High Frequency Follow-On (UFO), 
Commercial Broadband Satellite Program (CBSP), Commercial Wideband Satellite 
Program (CWSP), Defense Satellite Communications System (DSCS), Military Strategic 
and Tactical Relay (MILSTAR), International Marine and Maritime Satellite 
(INMARSAT), and others. Shore communications nodes are represented by ground 
receiving antenna icons which also represent multiple systems that range from large fixed 
site Standardized Tactical Entry Point (STEP) locations to man portable antenna systems. 



Figure 22. Aircraft Carrier Strike Group based FY2020 Joint ASW C4I 
Architecture Baseline 

This C4I network architecture is representative of real world carrier strike group communications 
depicting tactical line-of-sight and strategic beyond line-of-sight communications paths between 
maritime operators and shore based support sites. 


Each of the nodes in Figure 22 was further decomposed into the individual 
systems peculiar to each node that physically perform the functions identified in the Joint 
ASW C4I functional architecture. Current 2008 systems were used for the 
decomposition of each individual node because the systems planned for FY2020 have not 
yet been developed and system connectivity is not available. Therefore, the discussions 
and descriptions pertaining to the data flow through the systems peculiar to each node are 
based on 2008 systems. However, the systems that are planned to be fielded by the 
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FY2020 are noted next to each 2008 system for which the FY2020 system is slated to 
replace in the graphical descriptions. The FY2020 systems are also noted on the 
drawings next to the 2008 system for which it is intended to replace. 



Figure 23. Joint ASW C4I Architecture Baseline Aircraft Carrier Node 
Configuration 

This figure is representative of the systems that exist on an aircraft carrier that are used in the 
execution of anti-submarine warfare. This figure is the expansion of the CYN node in Figure 22. 

The decomposition of the aircraft carrier node into the systems that make up the 
physical architecture required to meet the ASW C4I functional architecture are illustrated 
in Figure 23. The flow of data through the physical architecture of an aircraft carrier 
node moves from the left side of Figure 23 to the right side where the processed data is 
distributed to other nodes by way of the systems that provide RF distribution. The left 
side of Figure 23 illustrates the sensors peculiar to an aircraft carrier that are used to 
conduct anti-submarine warfare. The NECC system collects the ASW sensor data from 
the encrypted sensor data received from other nodes by way of the various RF 
communication links and onboard ASW sensors. The Common Data Link Management 
System (CDLMS) and the Automated Digital Network System receive the encrypted 
sensor data from the radio frequency distribution communication links and pass it 
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through the CANES to NECC. The NECC system then fuses the data received from 
multiple sensors and the NECC operators manually generate the COTP. 

The combined ASW sensor data from the TSC-M is also provided to the Ship Self 
Defense System (SSDS). The picture developed by the TSC-M system is provided to the 
NECC system for incorporation into the COTP and the CANES and Shipboard Video 
Display System (SVDS) distributes the COTP to all operator workstations and command 
centers that require it. The COTP generated by the NECC system is distributed to 
individual workstations and operators in the Combat Direction Center (CDC) by way of 
the CANES system and SVDS. The operators in the CDC use the COTP generated by 
the NECC system and displayed by SVDS on large screen displays and video walls to 
make decisions as to which targets or tracks to engage using the SSDS system and 
Cooperative Engagement Capability (CEC) Systems. The aircraft carrier has the Surface 
Ship Torpedo Defense System (SSTD) to protect itself against enemy submarines. 

Once the NECC system collects all of the sensor data from ADNS and CDLMS 
and the COTP has been generated, the COTP is then transmitted back through ADNS and 
CDLMS for the purpose of distributing the COTP to other nodes by way of the RE 
Distribution communication links (same once used to collect ASW sensor data external to 
the aircraft carrier). The COTP is then used by other nodes in a similar manner as the 
aircraft carrier node to conduct command and control. The COTP is used by decision 
makers to decide which targets to track and engage using the node specific sensor and 
weapon systems. If the aircraft carrier node is designated as the central hub for collecting 
and fusing sensor data and generating the COTP, then the COTP generated would be 
referred to as the Top COTP. The Top COTP can be designated to take place at any node 
illustrated in Figure 22. The sharing of the Top COTP is done by way of the RE 
Distribution communication links characteristic of each node in the baseline. 

Furthermore, the entire strike group and all nodes operating within the strike group 
including shore locations have the capability to generate and share the COTP by way of 
the RF communication links. All assets within a strike force which includes United 
States, NATO, and coalition aircraft, ships and ground forces use the sensors available to 
them to locate and track friendly, unfriendly, and unknown entities or tracks. That 
information is then provided back to a central NECC node that collects the data, fuses the 
data and generates the Top COTP. External NECC nodes include ISR platforms such as 
unmanned aerial vehicles, electronics intelligence aircraft and ground-based assets, 
special operations forces, and meteorological and messaging activities. Other nodes may 
include higher-level combatant commands, commanders, and decision-makers. NECC 
fuses ISR, tactical tracks, battle damage assessment, weather, and formatted message data 
from multiple wired and radio communications links including satellite communications, 


89 



tactical data links, the Secret Internet Protocol Router Network (SIPRNet), and eoalition 
networks to form the Top COTP. The proeess previously described is a eontinuous 
proeess. 


SENSQfiS ija£R.gB!QUe8 DISTRIBUTION AND SWITCHING RF DISTRIBUTION 



Figure 24. Joint ASW C4I Architecture Baseline Cruiser and Destroyer Node 
Configuration 

This figure is the expansion of the DDG and CG nodes in Figure 22. This figure is representative of 
the systems that exist on Arleigh Burke Destroyers and Aegis Cruisers that are used in the execution 
of anti-submarine warfare. 

A similar breakout of system connectivity for the cruiser and destroyer nodes is 
illustrated in Figure 24. The data flow for the CG and DDG nodes are identical to the 
data flow described for the CVN node in Figure 23. Each of the node system 
connectivity drawings are arranged to show data flow from the sensors to the user groups 
to the distribution and switching functions to RF distribution from left to right. Common 
to each node are NECC, CANES, ADNS and various radio frequency distribution 
satellite and line-of-sight external communication systems. Each type of platform (CG, 
DDG, CVN, SSN and various aircraft) has its own unique set of sensors and weapon 
systems. The common system shared between all ships, aircraft coalition partners and 
shore facilities that perform the data fusing and COTP development functions is the 
NECC system. 
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Figure 25. Joint ASW C4I Architecture Baseline Submarine Node 
Configuration 

This figure is the expansion of the SSN-668 and SSN-774 nodes in Figure 22. This figure is 
representative of the systems that exist on Los Angeles and Virginia Class Attack Submarines that 
are used in the execution of anti-submarine warfare. 


The system connectivity diagram for the submarine node is depicted in Figure 25. 
Other system connectivity diagrams for other nodes depicted in Figure 22 are included in 
Appendix G. Some sections of the system connectivity drawings listed in Appendix G 
are labeled as unknown because the specific sensors, weapons, user groups and 
communication systems pertaining to these platforms are not available. As a means to 
fill the gaps in the communication baseline for the submarine node, a quote from the 
PEO-C4I Masterplan was used that describes in better detail, the make up of the systems 
on a submarine communication node. 

In FYIO to FY12 the submarine radio room will increase 
their baseline capabilities by adding Satellite and Line-of-Sight 
waveforms. Joint Tactical Radio and Mobile User Objective 
System (MUOS) transceivers, changing from a SubHDR (OE-562) 
antenna to an Advanced HDR antenna, adding Communications at 
Speed and Depth, adding security enclaves for access to Allied 
information and simultaneous access to different compartmented 
information, and by adding capabilities to provide quality of 
service to applications in a service-oriented architecture. ADNS 
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will be upgraded to ADNS INC III and NAVMACS will be 
replaced by ISDS Inc 2. 

The addition of the ADV HDR antenna adds significant 
additional bandwidth capability by introducing a larger aperture 
antenna into the submarine antenna mix and includes the addition 
of Ka-band. The upgrade of the OE-538 antenna to increment 2 
capabilities will include the Mobile User Objective System 
waveform, an L-Band antenna for access to LOS internet protocol 
waveforms and the IRIDIUM waveform. The LOS internet 
protocol waveforms are now included in Naval Tactical Networks 
and may include the Wideband Networking Waveform, the Soldier 
Radio Waveform, and a tactical airborne waveform. The addition 
of CSD capabilities will allow the submarine to access satellite and 
LOS services while maintaining the submarine in a stealth posture 
below periscope depth and provide the tactical commander with 
the capability to change submarine tasking without waiting for the 
next scheduled submarine communications window. 

The addition of super high frequency capability in the 
Follow-on Terminal or Navy Multi-band Terminal will 
significantly increase the internet protocol bandwidth available to a 
submarine that is not operating in a region covered by an 
extremely high frequency spotbeam. Additionally, commercial 
satellite communications in the super high frequency band may be 
available in regions covered by the XTAR satellite footprint. The 
addition of MUOS capability in either the JTRS AMF Increment 1 
radio or in Digital Modular Radio will provide dynamic ultra high 
frequency internet protocol connectivity at higher data rates then 
the shared 32 Kbps available in the baseline. 

ADNS INC III brings a change from the baseline 
architecture with the installation of a Ciphtertext Core. All 
enclaves will be encrypted over this Core. Capability 
improvements provided by ADNS INC III include Quality of 
Service, internet protocol version 6 capable networks, improved 
interoperability with ciphtertext routing, and the ability to access 
multiple satellite communications and LOS internet protocol 
networks simultaneously. ADNS INC III also provides the 
replacement path for Crypto Modernization of the in-line network 
encryptors. 

Additional new capability is provided by the addition of 
JWICS and one or more Combined Enterprise Regional 
Information Exchange, System (CENTRIXS) enclaves and by the 
inclusion of GCCS-M segments such as Joint Range Extension. 

The CENTRIXS enclave allows the submarine to exchange 
information with Allied nations, including participation in chat 
rooms and websites. The JWICS enclave supports passing of 
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intelligence in support of the Intelligence, Surveillance and 
Reconnaissance and Special Operating Forces missions. 

The Los Angeles Class has 1 OE-538, 1 OE 562, 1 OE-315, 
1 Typel8,and 1 OE-499 antennas, while an SSGN has 2 OE-538, 2 
OE -562, 1 OE 315, 2 BRA-6, 1 Type 15 and 1 OE-499 antennas. 
The SSBN is the same as the SSGN with the exception of using 2 
OE-592 antennas vice 2 OE-538 antennas. The SSGN has 2 EHF 
follow-on terminals while all other classes have only 1. The SSBN 
has 3 Submarine LFA^LR Receivers while all other classes have 
only one [PEO C4I Masterplan, 2007: 246]. 


The previous descriptions of systems for each node (Figure 23, Figure 24, and 
Figure 25) are the systems that make up the physical architecture of the Joint ASW C4I 
Architecture. These are the systems that were used to decompose the ASW functional 
architecture into the physical architecture required to perform the ASW functions. 
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Figure 26. 2008 Communication Interconnectivity between Nodes 

This figure shows the current (2008) communication interconnectivity between nodes for the 
purpose of comparing today’s communication links to the communication links planned to be 
operational in 2020. 
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Figure 27. 2020 Communication Interconnectivity between Nodes 

This figure shows the planned communication interconnectivity between nodes in characteristic if 
the FY2020 Joint ASW C4I Architecture Baseline. 
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Figure 28. Military Satellite Communication Systems of Systems Schedule 

This figure shows the schedule that detail the transitional period from existing communication 
systems to the ones identified in the FY2020 Joint ASW C4I Architecture Baseline [Cinlemis, 
2005], 
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Figure 29. Tactical Radio Roadmap 

This figure shows the sehedule that detail the transitional period from existing tactieal radio 
eommunieation systems to the JTRS identified in the FY2020 Joint ASW C4I Architecture 
Baseline [PEO C4I Masterplan, 2007: 30]. 


Figure 26 illustrates a simplified configuration of the communication systems that 
are currently in use today. The red lines depict satellite communications, the blue lines 
represent surface to surface and surface to air line-of-site communications combined with 
the tactical data links (TDLs) and the green lines represent the communications at speed 
and depth for the submarine. The 2008 configuration is shown for the purpose of 
illustrating the changes from the systems that perform Joint ASW C4I functions today 
and the systems that are planned to perform Joint ASW C4I functions in 2020. Figure 27 
depicts the updated 2020 version of Figure 26 that includes the systems planned to be 
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fielded by year 2020. Figure 27 illustrates the line-of-sight and satellite communication 
systems that make up the FY2020 Joint ASW C41 Architecture Baseline. Figure 26 and 
Figure 27 were provided to highlight the changes planned for FY2020. Defense Satellite 
Communications System (DSCS) is planned to be replaced by the Wideband Global 
Satellite Communication (WGS) system. “The Wideband Global SATCOM, or WGS is 
the replacement for the current DSCS and as a significantly more capable satellite, it will 
provide improvements in the data throughput available to Navy users. It is expected, 
with the combination of the EBEM and the WGS, Navy shipboard users will see a more 
than doubling of the currently allocated data rates” [PEG C4I Masterplan, 2007: 44]. 
MILSTAR is planned to be replaced by the Advanced EHF system. “Advanced EHF 
satellites will provide 10 times greater total capacity and offer channel data rates four 
times higher than that of MILSTAR II communications satellites. The higher data rates 
permit transmission of tactical military communications such as real-time video, 
battlefield maps, and targeting data” [PEG C4I Masterplan, 2007: 47]. The CWSP 
system is planned to be replaced by the CBSP system. “The CBSP architecture is 
currently undefined but is expected to continue as an augment to military satellite 
communications while providing significantly more capacity to users than the current 
CWSP program” [PEG C4I Masterplan, 2007: 44]. There are currently no planned 
upgrades to INMARSAT but the CBSP system may provide some of this capability. The 
Enhanced Polar satellite system is intended to provide polar orbit satellites that will 
enhance the coverage of the Advanced EHF system. 

For satellite communication systems, the addition of the optical laser 
communication system depicted in Figure 27 is one of the major improvements expected 
to improve communications with submarines at speed and depth. This system is expected 
to allow the submarine to be part of strike group while submerged and is one of the 
primary gaps in the communication links for the Joint ASW C4I Architecture. Without 
the implementation of this system or one similar the current communication gap to a 
submerged submarine will still exist in the FY2020 Joint ASW C4I Architecture. 

The UFG satellite communications system shown in Figure 26 will be replaced by 
the Mobile User Gbjective System (MUGS) satellite communication system. The 
maximum narrowband throughput for the UFG system is 19.6 kilobits per second per 
channel. With the implementation of the MUGS system the throughput will go up to 64 
kilobits per second per channel. The MUGS system is fully compatible with JTRS and 
the existing UFG terminal system. In addition submarines will be using MUGS and the 
existing IRIDIUM satellite system to communicate with other nodes using tethered buoys 
and RF to Acoustic gateways. 
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Transformational Satellite System (TSAT) is another addition to the ASW C4I 
physical architecture planned for the FY2020 timeframe. “The Transformational Satellite 
System (TSAT) provides orbit-to-ground laser and RF communications. The 
Transformational Satellite Communications System will provide DoD with high data rate 
Military Satellite Communications and Intemet-like services as defined in the 
Transformational Communications Architecture. TSAT is key to global net-centric 
operations” [PEO C4I Masterplan, 2007: 21]. 

Figure 28 illustrates the transitional period from existing communication systems 
to the ones identified in the FY2020 Joint ASW C4I Architecture Baseline [Cinlemis, 
2005]. According to this schedule, all of the system identified in the ASW C4I physical 
architecture are expected to be in place and operational. Any lack of funding or failure to 
implement affects the ASW C4I physical architecture. 

For line-of-sight communications, the systems are depicted by the blue and green 
lines in Figure 27. The systems in use today are Multifunctional Information Distribution 
System (MIDS) on Ship (MOS), Battle Force Email (BFEM), High Frequency (HF) 
Automatic Link Establishment (ALE), Digital Wideband Transmission System (DWTS), 
Single Channel Ground and Airborne Radio System (SINCGARS), Enhanced Position 
Location Reporting System - Data Radio (EPLRS-DR), Subnet Relay (SNR), AN/URC- 
131(V) known as High Frequency Radio Group (HFRG), the very high frequency 
military radio band fi'om 30 megahertz to 88 megahertz and the ultra high frequency 
communication system supporting line-of-sight communications between accomplishing 
units and is comprised of several different radio groups or subsystems such as AN/WSC- 
3, Digital Modular Radio (DMR), and AN/ARC-210. Included in the line-of-sight 
communication systems are Link-16, Link-11, Link-1 IB, and Link-4. For the 2020 
timeframe, the JTRS will replace the current high frequency, very high frequency, ultra 
high frequency, and DWTS systems. The Joint Tactical Radio System will combine the 
functionality of numerous single function radios among the services into a single, joint- 
interoperable family of radios. Figure 29 depicts the current PEO-C4I plan to migrate 
from these legacy line-of-sight systems to the JTRS. 

It is expected that every system listed in Table 4 will be fielded by year 2017 and 
will be included in the Joint ASW C4I Architecture Baseline. The JTRS with wideband 
network waveforms (WNW) was identified as the 2020 baseline system for line-of-sight 
and tactical data links and are illustrated with blue lines in Figure 26. For the wideband 
satellite communication systems, the transformational satellite system (TSAT), the 
Wideband Gapfiller System (WGS), and the Commercial Broadband Satellite Program 
(CBSP) were identified as part of the Joint ASW C4I Architecture Baseline. For the 
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protected satellite communication systems, the Advanced Extremely High Frequency 
(AEHF) system and the Enhanced Polar System (EPS) were selected. For narrowband 
ultra high frequency (UHF) satellite communications, the Mobile User Objective System 
satellite constellation system was selected. For the submarine communications at speed 
and depth shown as green lines in Figure 27 there are several communication methods 
that rely on the Iridium satellite constellation and the MUOS satellite constellations. 

Other submarine CSD include the optical laser communications system, the buoyant 
cable antenna with high frequency over internet protocol, the buoyant cable antenna with 
high frequency Special Radio Variant, the Tethered Expendable Communications Buoy 
(TECB) using the Iridium constellation, the Tethered Expendable Communications Buoy 
using the MUOS ultra high frequency constellation, the Acoustic to radio frequency 
Gateway (A2RF) System, and the Tethered Reconfigurable Expendable Buoy system. 
There are discussions ongoing to determine of the OLC system will be initially hosted by 
TSAT or MUOS satellites when initially executed [Reddish and Lovem, 2007]. These 
systems in conjunction with the JTRS, ADNS, NECC, CANES, Link-16 and USW-DSS 
make up the FY2020 Joint ASW C4I Architecture Baseline. Table 4 lists the systems just 
described in a tabular format so the reader can easily determine which systems were 
selected as part of the FY2020 Joint ASW C4I Architecture Baseline. 
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Table 4 . FY2020 Joint ASW C4I Physical Architecture 

This table maps the physical architecture for the functions identified as gaps in the ASW 

functional architecture in the FY2020 Joint ASW C4I Architecture Baseline. 

3. Conduct Functional Gap Analysis 

The functional gap analysis compared the future capabilities of systems planned 
to be fielded under DoD program of record initiatives against the functional architecture 
established earlier in this report as well the current year’s list of Top 10 Fleet 
Requirements and comments received from stakeholders throughout this project. It was 
necessary to make several assumptions to establish a solid starting point which include: 
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• All seven programs of record identified in the C4I Masterplan are completely 
funded and the resulting functional capabilities would be fielded on time prior 
to reaching the FY2020 timeframe. 

• Current year resources were properly accounted for by the United States Navy 
in the FYIO to 15 program objective memorandum and did not lead to 
reduction of the capabilities specified in the FY2020 Joint ASW C4I 
Architecture Baseline. 

• The ASW community will ensure full procurement and operational life cycle 
funding of all available technologies initiated in today’s science and 
technology communities. 

• The ASW community will take advantage of all design study interfaces to best 
leverage opportunities to close all functional gaps identified in this study. 

DoD programs of record are key to the success of the FY2020 Joint ASW C4I 
Architecture Baseline. Although twelve years away, programs being planned for and 
funded today to address ASW C41 shortfalls will be solutions counted on in FY2020. 
Table 5 lists the program of record systems and their expected capabilities outlined by the 
PEO C41 Masterplan. Summaries of the DoD programs of record identified in the C41 
Masterplan are provided to detail the planned capabilities for use in the FY2020 Joint 
ASW C41 Architecture Baseline: 

Global Information Grid 

The GIG enables a world-wide, end-to-end set of information capabilities, 
associated processes, and personnel for collecting, processing, storing, disseminating, and 
managing information on demand to warfighters, policymakers, and support personnel. 
The GIG includes all owned and leased communications and computing systems and 
services, software (including applications), system data, security services, and other 
associated services necessary to achieve information superiority for the United States 
military. 

Transformational Satellite System 

TSAT is the key component to conducting global net-centric operations which 
provide orbit-to-ground laser and radio frequency communications. The TSAT system 
will provide the ASW community with high data rate military satellite communications 
and Intemet-like services as defined in the Transformational Communications 
Architecture (TCA). TSAT is the GIGs space borne element extending the GIG to users 
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without terrestrial connections providing improved connectivity and data transfer 
capability, vastly improving satellite communications for the warfighter. 

DoD Teleport 

The DoD Teleport system, implemented by the Defense Information Systems 
Agency, integrates, manages, and controls a variety of communications interfaces 
between the Defense Information System Network terrestrial and tactical satellite 
communications assets at a single point of presence. DoD Teleport is a 
telecommunications collection and distribution point, providing deployed warfighters 
with multi-band, multimedia, and worldwide reach-back capabilities to DISN that far 
exceed today’s capabilities. Teleport is an extension of the Standardized Tactical Entry 
Point program, which currently provides reach-back for deployed warfighters via the 
Defense Satellite Communications System X-band satellites. This new system provides 
additional connectivity via multiple military and commercial satellite communications 
systems, and it provides a seamless interface into the DISN. The system provides inter- 
and intra-theater communications through a variety of satellite communications choices 
and increased DISN access capabilities. 

Net-Enabled Command Capability 

NECC is DoDs principal command and control capability accessible in a net- 
centric environment and focused on providing the commander with data and information 
needed to make timely, effective, and informed decisions. NECC draws from the 
command and control community to evolve current and provide new C2 capabilities into 
a fully integrated, interoperable, collaborative Joint solution. Warfighters can rapidly 
adapt to changing mission needs by defining and tailoring their information environment 
and drawing on capabilities that enable the efficient, timely, and effective command of 
forces and control of engagements. It was assumed that the Global Command and 
Control System - Maritime program will be completely migrated into the Joint Net- 
Enabled Command Capability program by the FY2020 timeframe. 

Joint Tactical Radio System 

JTRS is an important area of improvement assumed to be in place for operational 
use by the ASW community in the FY2020 timeframe. It will provide a co mm on 
platform for wireless applications, ranging from low cost, single purpose terminals, to 
multi-band, multi-mode, multi-channel voice and data radios supporting narrowband and 
wideband waveforms. JTRS family of tactical radios supports line-of-sight and beyond 
line-of-sight C4I capabilities. It will be capable of transmitting voice, video and high¬ 
speed data. The program will support vehicular, airborne and portable configurations 
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including man portable, handheld and Small Form Factor for a variety of mission 
requirements. 

Net-Centric Enterprise Services 

The NCES program provides enterprise services in support of the GIG. NCES 
will provide DoD organizations ubiquitous access to reliable, decision-quality 
information through a net-based serviees infrastructure and applications to bridge real¬ 
time and near-real-time eommunities of interest. NCES will empower the edge user to 
pull information from any available souree, with minimal lateney, to support the mission. 
Its eapabilities will allow GIG users to task, post, process, use, and store, manage and 
proteet information resourees on demand for operational users, poliey makers and support 
personnel. 

Next Generation Enterprise Networks (NGEN) 

NGEN is assumed to be in place for use in the FY2020 Joint ASW C4I 
Arehitecture Baseline. It will focus on the integration of some or all of the components 
that make up the Navy’s other networks sueh as ONEnet and BLII, into a single 
enterprise network. Other architectural efforts being leveraged by NGEN are FORCEnet, 
CANES, Sea Warrior and Distant Support to move towards open architeeture and 
service-oriented arehiteeture concepts. 
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. ONEnet&BLII 
. Components 
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Table 5. Programs of Record Functional Capability Relationships 

This table offers quick reference to functional C4I capabilities being programmed by DoD yielding a 
joint service C4I networked architecture. 


During the execution of the functional gap analysis it was clear that the 
“Interconnect Communication Nodes” function is a functional gap that most affects the 
submarine operating at speed and depth in the Joint ASW C4I Architecture. Today, there 
is a recognized lack of a direct high bandwidth two-way communications links between 
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the submarine and surfaee assets including satellite and line-of-sight communication 
systems while the submarine is operating at speed and depth. The FY2020 Joint ASW 
C4I Architecture Baseline addresses this functional gap by including the use of an optical 
laser communication system that is planned to be implemented by FY2020 but was not 
included as part of the planned systems in the PEO-C4I Masterplan. In order for the 
submarine to be included in the overall communication network depicted in the FY2020 
Joint ASW C4I Architecture Baseline, it will have to rely on the OLC system as well as 
other tethered communication buoys plarmed for communications at speed and depth. 
None of these tethered buoy options offer a high bandwidth solution to communicating 
with the submarine at speed and depth. The OLC system is the only system found by 
research to provide a high bandwidth two-way communications path for a submerged 
submarine operating at speed and depth. Since the target of interest for the ASW 
community is an enemy submarine, it is advantageous to be able to have two-way high 
bandwidth real time communications between a stealthy submerged submarine and 
surface assets engaged in the ASW effort. Therefore, there is a potential for an 
“Interconnect Communication Nodes” functional gap without the implementation of the 
OLC system. If the OLC system is not funded and implemented then there will be a 
functional gap for high bandwidth two-way communications with any submarine 
operating at speed and depth. The tethered buoy options will meet the functional gap but 
at very low bandwidth rates which will be very difficult for real-time sharing of sensor 
data and the COTP. This possible functional gap was equated to Function A. 1.1 - 
Interconnect Communication Nodes because there is a risk that the systems planned for 
FY2020 may not get implemented. Research indicated that maritime communications 
will continue to require the current levels of bandwidth, and more, and will need to 
maximize the use of the existing frequency spectrum. 

The other functions identified from the functional analysis as possible gaps are the 
Fuse ASW Data, Provide ASW COTP and Distribute COTP. Today the current systems 
that provide these functions are ADNS, GCCS-M and ISNS. For the FY2020 Joint ASW 
C4I Architecture these functions will be accomplished by ADNS Inc III+, NECC and 
CANES. The reason that these functions were identified as possible gaps is because of 
the current levels of throughput and fusion (Level 1) currently being done by existing 
systems. It is expected that NECC will provide a higher level of data fusion by the 
FY2020 timeframe and that ADNS and CANES will have evolved to a level of maturity 
where the distribution of sensor data and the COTP will be at or near real-time. 

Therefore the functions of interest identified by the functional gap analysis include 
Function A.5.1 - Fuse ASW Data; Function A.5.2 - Provide ASW COTP; and Function 
A.5.3 - Identify, Store, Share and Exchange ASW Data and Information. Although the 
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current C4I systems in plaee today and the systems planned for FY2020 provide basic 
functionality for these functions, it was deemed neeessary to inelude them as possible 
funetional gaps because of the levels of throughput and fusion eapabilities. 

Therefore, the functional gaps identified by the functional gap analysis are 

• A. 1.1 - Interconneet Communication Nodes; 

• A.5.2 - Fuse ASW Data; 

• A.5.1 - Provide ASW Common Operational Tactical Picture and 

• A.5.3 - Identify, Store, Share and Exehange ASW Data and Information. 

The program of reeord systems listed in Table 5 were identified as future planned 
systems that are expected to fill the functional gaps identified by the functional gap 
analysis. The Joint ASW C4I Architeeture Baseline depends on these systems being 
funded and implemented. 

4. Consolidate Value Hierarchy and Stakeholder Analysis 

Concurrent with the functional gap analysis, a value hierarehy stakeholder survey 
of the functional architecture was condueted. The intent of the value hierarchy 
stakeholder survey was to ascertain a relative value for eaeh function in the value 
hierarehy; identify the most critieal sub-functions in the value hierarehy and gain 
feedback on the proposed evaluation measures. 

From the Value System Design seetion of this report, the highest ranked functions 
in terms of importanee to the stakeholders were Function A.5.2 - Provide ASW COTP; 
Funetion A.5.1 - Fuse ASW Data; Function A. 1.1 - Interconnect Communication Nodes; 
and Funetion A.5.3.4 - Enable Smart Pull and Push of ASW Information. As a result of 
the value hierarchy stakeholder survey, the stakeholders identified fiinetions that they 
pereeived as needing attention and were translated into a set of funetional gaps. The 
eombination of the funetional gap analysis and the stakeholder analysis narrowed the 
foeus of funetional gaps to the A.l Provide Connectivity and A. 5 Provide ASW Data 
Information Management upper level functions. The results of the two analyses were 
used to examine, evaluate, and derive viable alternative network architectures that most 
aligns with stakeholder needs. 

5. Brainstorm Alternative Solutions 

The researeh into future teehnologies eontributed to the far reaching out year 
capabilities desired of the alternatives. Value hierarchy contributions offered solutions 
contributing to stakeholder identified functional gaps. This capstone projeet design team 
sought to identify ways and means to address functional gaps of the FY2020 Joint ASW 
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C4I Architecture Baseline resulting from the consolidated functional analysis initiatives. 
DOTMLPF items needed to be identified that would close or fill the four possible 
functional shortfalls identified above: Function A. 1.1 - Interconnect Communication 
Nodes; Function A.5.1 - Fuse ASW Data; Function A.5.2 - Provide ASW COTP; and 
Function; A.5.3.4 - Enable Smart Pull and Push of ASW Information. 

Interfacing or communicating with and between sensors and ASW nodes requires 
a vast knowledge of existing C4I techniques, architecting network topologies to attain the 
highest quality C4I architectural footing, and own system specifications to get the most 
benefit in making the interface. Programs of record appear to have met many of the 
functional gaps well into the FY2020 timeframe. This capstone project design team 
maintained it is most difficult to attain high quality robust communications between 
submarines operating at speed and depth. Brainstormed solutions included on board and 
off board submarine systems communication relay devices that would be moored or 
distributed for submarine or fleet wide use to bridge the air-sea interface gap. Thoughts 
also were directed at powering data signals directly to the submarine using x-rays, lasers, 
and other signaling devices that could be used from United States Navy, coalition force, 
or joint force surface, air, or space platforms. 

Fused data rests on the ability of the systems collecting sensor data from multiple 
sensors; the systems collating and assigning the sensor data to a specific target or track; 
and the systems used to create a track that contains multiple sensor data used to generate 
the COTP that can be used by Combatant Commanders to rapidly make a decision. 
Improvements in software applications, additional data recognition training for 
operational users, and hardware capabilities to more readily move and translate data 
formats were offered as possible solutions. 

The function that enables smart pull and push of ASW information could improve 
the delivery of the COTP by refining data agreements and improving the speed of 
merging significant strategic and tactical data. It was agreed that today’s programs of 
record are seeking to improve information exchange and operational performance to 
better support United States Navy and coalition decision makers and their supporting 
systems. Brainstorming ideas called out improvements for computer hardware systems 
and recognized the need for futuristic data storage and delivery techniques beyond the 
FY2020 Joint ASW C4I Architecture Baseline. 

B. ALTERNATIVE SOLUTIONS 

The following alternative solutions are made up of programs of record, non¬ 
programs of record, and proposed technologies. Table 6 is a matrix of four alternatives 
versus the four functions derived from the functional gap analysis. The systems that are 
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expected to perform the functions identified as functional gaps are listed in the body of 
the table. 
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FY2020 Baseline 

listed in Table 4 

plus 

- Satellite or high 

altitude aircraft 

based fusion of the 

common 

operational picture 
by means of 

HALO, Helios, and 

HAA 

FY2020 

Baseline listed 

in Table 4 plus 

- Wireless user 
capable of 
pulling and 
pushing 

information 

directly to a 
satellite or high 

attitude aircraft 

based network 

by way of 

HALO, Helios, 

and HAA 


Table 6. Alternative Solutions and Functional Gaps 

This table shows the four alternatives versus the functional gaps with the systems proposed to 
perform each function for each alternative. 
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Figure 30. Graphical Representation of the Systems Expected to Perform the 
Interconnect Communication Nodes Function for Alternatives 0,1, and 2 

This figure shows the systems that are planned to be implemented and operational by FY2020 
expected to perform the “interconnect communication nodes” function for the FY2020 Joint ASW 
C4I Architecture Baseline Alternatives 0, 1, and 2. 


Alternative 0 is the Baseline already discussed in some detail. It is based entirely 
on the planned program of record systems outlined by PEO-C4I in their PEO-C4I 
Masterplan version 1.0 dated 7 October 2007 and the submarine communications systems 
outlined by Reddish and Lovem in their “Communications at Speed and Depth and 
Optical Laser Communications Status” presentation [Reddish and Lovern, 2007]. All of 
the systems outlined by these two documents are planned to be in place by year 2020 and 
are included in FY2020 Joint ASW C4I Architecture Baseline. Figure 30 provides a 
pictorial representation of the interconnection between communication nodes function of 
the FY2020 Joint ASW C4I Architecture Baseline for Alternative 0. The FY2020 Joint 
ASW C4I Architecture Baseline Alternative 0 is expected to suffice in addressing the 
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current interconnection between nodes functional gap beyond the next twelve years. 

Table 7 lists the communication bandwidths for each system that will be used to model 
the performance of the “interconnection of communication node” function depicted in 
Figure 30. One of the evaluation measures associated with the “interconnection of 
communication nodes” function that will be used to conduct an analysis of alternatives is 
the network join time. The network join time for each communication path is listed in 
Table 7. In Table 7, the value for the network join time, effective throughput and 
bandwidth for the JTRS WNW increment 3 was obtained from the Tactical Data Link-T 
Capabilities Development Document [TDL-T CDD, 2003]. The bandwidth for the 
Optical Laser Communications (OLC) was derived from a briefing written by Reddish 
and Lovern titled, “Communications at Speed and Depth (CSD) and Optical Laser 
Communications (OLC) Status,” [Reddish and Lovern, 2007]. The bandwidth and 
effective throughput for the MUOS was derived from a document provided by the Navy 
Communications Satellite Program Office called “Mobile User Objective System 
(MUOS)” [Navy Communications Satellite Program Office, 2004] and a MUOS 
Datasheet provided by Ericsson titled “Proud Partner in MUOS” [Ericsson, 2006]. The 
information for the Link-16 bandwidth and effective throughput came from the Link-16 
subject matter expert Matthew Letoumeau. Table 7, Table 9, Table 11, and Table 13 
only have data for MUOS because it was deliberately chosen for simplicity sake to model 
the preferred communication paths. For line-of-sight surface to surface and surface to 
air, that is WNW. For surface to sub-surface that is CSD. For TDL, this is Link-16 and 
for SATCOM, it is MUOS. We did not want to expand the scope by looking at degraded 
operations or overflow operations and it has also been an assumption on our part that the 
Navy will be migrating from numerous stove-piped solutions to joint ubiquitous 
solutions. So, while other communication paths will likely exist in 2020, we wanted to 
focus on the preferred communications paths that are designed to provide superior 
performance and joint interoperability. CSD is somewhat Navy-centric but MUOS, 

Link-16, and WNW are clearly joint solutions. 
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Communicat 
ion Path 

System 

Network 

Join 

Time 

(sec) 

Effective 

Through 

put 

RF Bandwidth 

Laser Bandwidth 

T ransmi t/Recei ve 

Relay 

Delay 

Time 

(msec) 






Uplink 

Downlink 


Surface to 

JTRS 

5 

2 Mbps/ 

2 Mbps 



45 

Surface 

WNW 


# Users 





(LOS) 

Inc. 3 







Surface to 

JTRS 

5 

2 Mbps/ 

2 Mbps 



45 

Air 

WNW 


# Users 





(LOS) 

Inc. 3 







Surface to 

OLC 




224 Kbps 

1200 


Sub-surface 





@ 200 ft 

Kbps 


(LOS) 






@ 200 ft 


SATCOM 

MUOS 


64 Kbps 

64 Kbps 



500 


(UHF) 







TDL 

Link- 


8 Kbps 

53.7 Kbps 




(LOS) 

16 








Table 7. FY2020 Joint ASW C4I Architecture Baseline ^Tnterconnect 
Communication Nodes” Function Data Rates and Relay Delay Times for 
Alternative 0 


This table shows the bandwidths and effective throughputs of the systems that are part of the 
FY2020 Joint ASW C4I Architecture Baseline that are expected to perform the “interconnection 
between communication nodes” function for Alternative 0 [TDL-T CDD, 2003; Reddish and 
Lovem, 2007; Navy Communications Satellite Program Office, 2004; Ericsson, 2006; Letoumeau, 
2008]. 
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Figure 31. Internal System Connectivity for a Typical Node for Alternative 0 
and 1 

This figure shows the internal system connectivity for the systems that are part of the FY2020 
Joint ASW C4I Architecture Baseline that are expected to be fielded by FY2020 and represent a 
typical internal configuration of a typical node for Alternative 0 and 1. 


Figure 31 depicts the interconnection of systems that is typical of or common to 
each internal node configuration for Alternative 0. The following description describes 
the data flow through the systems depicted in Figure 31. 

The Net-Enabled Command and Control (NECC) system collects sensor data 
from on board sensors as well as sensor data from other nodes by way of the satellite 
communication links such as MUOS, AEHF and CBSP and line-of-Sight systems such as 
JTRS, Link-16 and other high frequency communication systems. The encrypted sensor 
data coming into the node from the external communication links are collected by the 
Automated Digital Network System (ADNS), unencrypted and distributed to the NECC 
system by way of the CANES system. The NECC system then fuses the sensor data from 
multiple sources into track information and generates the common operational tactical 
picture. Once the COTP has been created, it is distributed back through the CANES 
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network to ADNS where it is encrypted and transmitted by way of the various 
communication links to the other nodes. When the data is received at each subsequent 
node, the data is processed in the same way as just described. Figure 32 illustrates the 
data flow process for the system connectivity illustrated in Figure 31. 
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Figure 32. Data Processing Flow Diagram for Alternatives 0 and 1 

This figure shows the flow of sensor and COTP data through the systems represented in Figure 31. 
The estimated processing times are listed in Table 8. 


There are proeess times for each of data flow processes depicted in Figure 31. 
Table 8 lists the data process times characteristic of a typical node for Alternative 0 and 
were derived by expert opinion. 
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For the Provide COTP funetion, the assumption was made that all nodes in the 
Joint ASW C41 Arehiteeture Baseline will have the ability to receive the COTP by 
FY2020. This assumption is based the PEO-C4I Masterplan [PEO C41 Masterplan, 2007: 
58] that shows Link-4, Link-11, Link-16 and Link-22 all migrating to IP based 
waveforms near the year 2020 timeframe. Today there are a few of the nodes in the Joint 
ASW C4I Architecture Baseline such as the F/A-18 Hornet that does not receive the 
COTP. We expect by the year 2020 that those nodes will have the capability to receive 
the COTP. Therefore, the associated evaluation measure “percent of users with access to 
the COTP” for this function is expected to be at 100 percent in FY2020. 

The evaluation measure for the “Fuse ASW Data” function is “minimize data 
fusion processing time.” The value for this measure will be determined by modeling the 
fusion process. 

The evaluation measure for the “Enable Smart Pull and Push of ASW 
Information” function is the “user response time to critical information.” The “Enable 
Smart Pull and Push of ASW Information” function is a sub function under the “Identify, 
Store, Share and Exchange ASW Data and Information” function. The value for this 
measure will be determined by modeling and simulation using an average throughput 
derived from all communication paths listed in Table 7. 


Data Process 

System 

Data Process 
Time 

Interconnect Communication Nodes 

All 

4.2 sec 

Unencrypted Sensor Data 

ADNS 

100 msec [SSC 
Charleston Fleet 
Support Branch, 
2008] 

Distribute Unencrypted Sensor Data 

CANES 

100 msec [SSC 
Charleston Fleet 
Support Branch, 
2008] 

Fuse Unencrypted Sensor Data 

NECC 

200 msec [SSC 
Charleston Fleet 
Support Branch, 
2008] 

Update and Maintain COTP 

NECC 

Range: 20 to 120 
sec 

[SSC Charleston 
Fleet Support 
Branch, 2008] 
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Data Process 

System 

Data Process 
Time 

Distribute COTP 

CANES 

100 msec 
[SSC Charleston 
Fleet Support 
Branch, 2008] 

Encrypt COTP 

ADNS 

100 msec 
[SSC Charleston 
Fleet Support 
Branch, 2008] 

Distribute COTP to Communication Link(s) 

ADNS 

100 msec 
[SSC Charleston 
Fleet Support 
Branch, 2008] 


Table 8. FY2020 Joint ASW C4I Architecture Baseline Estimated Data 

Processing Times expected for Alternative 0 

This table shows a tabular representation of the data processes illustrated in Figure 32 with the 

approximated processing times for Alternative 0. 

2. Alternative 1 

Alternative 1 is all of the systems listed in Alternative 0 with expected 
improvements to JTRS and NECC. A part of these planned modifications will be the 
absorption of the Undersea Warfare Decision Support System (USW-DSS) into the 
NECC [Ross and Rupp, 2008]. It is assumed that there will be a decrease in the 
processing time and an increase in the level of fusion for the NECC system due to 
continuing improvements to the SOA structure. We made the assumption that the NECC 
system’s capability to Fuse Unencrypted Sensor Data will decrease (improve) to 150 
milliseconds. 

Figure 30 also represents the systems planned to provide the interconnection of 
communication nodes functionality for Alternative 1. No planned modifications to the 
satellite communications (SATCOM), Surface-to-Sub-Surface, CSD, and TDL 
communication systems are expected to increase throughput for this alternative. Changes 
due to the implementation JTRS WNW version 4.0 is expected to increase throughput 
and increase the bandwidth for surface-to-surface and surface-to-air communications. 
Table 9 lists the communication bandwidths for each system that will be used to model 
the performance of the interconnection of communication node function depicted in 
Figure 30. As in Alternative 0, the evaluation measure “network join time” will be used 
in an analysis of alternatives. The network join time for each communication path is 
listed in Table 9. 
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Communicat 
ion Path 

System 

Network 

Join 

Time 

(sec) 

Effective 

Through 

put 

RF Bandwidth 

Laser Bandwidth 

T ransmi t/Recei ve 

Relay 

Delay 

Time 

(msec) 






Uplink 

Downlink 


Surface to 

JTRS 

4.5 

2.2 

2.2 Mbps 



45 

Surface 

WNW 


Mbps/ 





(LOS) 

Inc. 4 


# Users 





Surface to 

JTRS 

4.5 

2.2 

2.2 Mbps 



45 

Air 

WNW 


Mbps/ 





(LOS) 

Inc. 4 


# Users 





Surface to 

OLC 




224 Kbps 

1200 


Sub-surface 





@ 200 ft 

Kbps 


(LOS) 






@ 200 ft 


SATCOM 

MUOS 


64 Kbps 

64 Kbps 



500 


(UHF) 







TDL 

Link- 


8 Kbps 

53.7 Kbps 




(LOS) 

16 








Table 9. FY2020 Joint ASW C4I Architecture Baseline “Interconnect 
Communication Nodes” Function Data Rates and Relay Delay Times for 
Alternative 1 


This table shows the bandwidths and effective throughputs of the systems that are part of the 
FY2020 Joint ASW C4I Architecture Baseline that are expected to perform the “interconnection 
between communication nodes” function for Alternative 1 [TDL-T CDD, 2003; Reddish and 
Lovem, 2007; Navy Communications Satellite Program Office, 2004; Ericsson, 2006; Letoumeau, 
2008], 


Figure 30 depicts the interconnection of systems that is typical or common for 
each internal node configuration for Alternative 1. The expected improvements in data 
processing time for Alternative 1 are shown in Table 10. 

For the “Provide COTP” function for this alternative as in Alternative 0, the 
assumption was made that all nodes in the Joint ASW C4I Architecture Baseline will 
have the ability to receive the COTP by FY2020. This assumption is based on the PEO- 
C4I Masterplan [PEO C4I Masterplan, 2007: 58] that shows Link-4, Link-11, Link-16 
and Link-22 all migrating to IP based waveforms near the year 2020 timeframe. Today 
there are a few of the nodes in the Joint ASW C4I Architecture Baseline such as the F/A- 
18 Hornet that does not receive the COTP. We expect by the year 2020 that those nodes 
will have the capability to receive the COTP. Therefore, the associated evaluation 
measure “percent of users with access to the COTP” for this function is expected to be at 
100 percent by FY2020. 
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The evaluation measure for the “Fuse ASW Data” funetion is “minimize data 


fusion processing time.” The value for this measure will be determined by modeling the 
fusion process. 

The evaluation measure for the “Enable Smart Pull and Push of ASW 
Information” function is the “user response time to critical information.” The “Enable 
Smart Pull and Push of ASW Information” function is a sub function under the “Identify, 
Store, Share and Exchange ASW Data and Information” function. The value for this 
measure will be determined by modeling and simulation using an average throughput 
derived from all communication paths listed in Table 9. 


Data Process 

System 

Data Process 
Time 

Interconnect Communication Nodes 

All 

4.2 sec 

Unencrypted Sensor Data 

ADNS 

100 msec 
[SSC Charleston 
Fleet Support 
Branch, 2008] 

Distribute Unencrypted Sensor Data 

CANES 

100 msec 
[SSC Charleston 
Fleet Support 
Branch, 2008] 

Fuse Unencrypted Sensor Data 

NECC 

150 msec 

Update and Maintain COTP 

NECC 

Range: 20 to 120 
sec 

[SSC Charleston 
Fleet Support 
Branch, 2008] 

Distribute COTP 

CANES 

100 msec 
[SSC Charleston 
Fleet Support 
Branch, 2008] 

Encrypt COTP 

ADNS 

100 msec 
[SSC Charleston 
Fleet Support 
Branch, 2008] 

Distribute COTP to Communication Link(s) 

ADNS 

100 msec 
[SSC Charleston 
Fleet Support 
Branch, 2008] 


Table 10. FY2020 Joint ASW C4I Architecture Baseline Estimated Data 
Processing Times for Alternative 1 

This table shows a tabular representation of the data processes illustrated in Figure 32 with the 
approximated processing times for Alternative 1. 
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3. Alternative 2 

Alternative 2 includes all of the systems listed in Alternative 0 with expected 
improvements to JTRS and NECC. This alternative includes another improvement to the 
interconnection of communication nodes function by including JTRS WNW increment 5. 
Table 11 shows the expected improvements in bandwidth for the addition of the JTRS 
WNW increment 5 for Alternative 2. As in Alternative 1, the evaluation measure 
“network join time” will be used in an analysis of alternatives. The network join time for 
each communication path is listed in Table 11. 


Communicat 
ion Path 

System 

Network 

Join 

Time 

(sec) 

Effective 

Through 

put 

RF Bandwidth 

Laser Bandwidth 
Transmit/Receive 

Relay 

Delay 

Time 

(msec) 






Uplink 

Downlink 


Surface to 

Surface 

(LOS) 

JTRS 
WNW 
Inc. 5 

2.5 

3 Mbps/ 

# Users 

3 Mbps 



25 

Surface to 

Air 

(LOS) 

JTRS 
WNW 
Inc. 5 

2.5 

3 Mbps/ 

# Users 

3 Mbps 



25 

Surface to 

Sub-surface 

(LOS) 

OLC 




224 Kbps 
@ 200 ft 

1200 

Kbps 
@ 200 ft 


SATCOM 

MUOS 

(UHF) 


64 Kbps 

64 Kbps 



500 

TDL 

(LOS) 

Link- 

16 


8 Kbps 

53.7 Kbps 





Table 11. FY2020 Joint ASW C4I Architecture Baseline “Interconnect 
Communication Nodes” Function Data Rates and Relay Delay Times for 
Alternative 2 

This table shows the bandwidths and effective throughputs of the systems that are part of the 
FY2020 Joint ASW C4I Architecture Baseline that are expected to perform the “interconnect 
communication nodes” function for Alternative 2 [TDL-T CDD, 2003; Reddish and Lovem, 2007; 
Navy Communications Satellite Program Office, 2004; Ericsson, 2006; Lefoumeau, 2008], 


For the A.5.1 function, incremental improvements in the net enabled co mm and 
capability system listed in the previous alternatives are expected to provide a higher level 
of data fusion capability. In addition, it is expected that the NECC system will be 
consolidated into the CANES system as well as the consolidation of all standard services. 
It is also expected that the CANES system will establish the ability to create community 
of interest applications and integrate them into the CANES environment thereby reducing 
stove-piped hardware solutions into software applications within the CANES/NECC 
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system. Research and study into providing this capability is being conducted by means of 
the JTM study which is expected to make recommendations for the replacement and 
improvement of the Net-Enabled Command Capability (NECC) system in fiscal year 
2012 and carry through past the FY2020 timeframe. 

Figure 33 depicts the interconnection of systems that will be typical of internal 
node system connectivity Alternative 2. Figure 34 depicts the process data flow for ASW 
sensor and COTP data. This consolidation is expected to improve the data processing 
rates by the amounts shown in Table 12. 



Figure 33. Internal Node System Connectivity with NECC absorbed into the 
CANES System for Alternative 2 

This figure shows the internal system connectivity for the systems that are part of the FY2020 
Joint ASW C4I Architecture Baseline that are expected to be fielded by FY2020 and represent a 
typical internal configuration of a typical node for Alternative 2. 
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Figure 34. Data Processing Flow Diagram for Alternative 2 

This figure shows the flow of sensor and COTP data through the systems represented in Figure 33. 
The estimated processing times are listed in Table 12. 
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Data Process 

System 

Data Process Time 

Interconnect Communication Nodes 

All 

4.2 sec 

Unencrypted Sensor Data 

ADNS 

100 msec 

[SSC Charleston Fleet 

Support Branch, 2008] 

Distribute Unencrypted Sensor Data 

CANES 

100 msec 

[SSC Charleston Fleet 

Support Branch, 2008] 

Fuse Unencrypted Sensor Data 

CANES 

100 msec 

Update and Maintain COTP 

CANES 

Range: 20 to 120 sec 
[SSC Charleston Fleet 

Support Branch, 2008] 

Distribute COTP 

CANES 

100 msec 

[SSC Charleston Fleet 

Support Branch, 2008] 

Encrypt COTP 

ADNS 

100 msec 

[SSC Charleston Fleet 

Support Branch, 2008] 

Distribute COTP to Communication 
Link(s) 

ADNS 

100 msec 

[SSC Charleston Fleet 

Support Branch, 2008] 


Table 12. FY2020 Joint ASW C4I Architecture Baseline Estimated Data 

Processing Times for Alternative 2 

This table shows a tabular representation of the data processes illustrated in Figure 34 with the 

approximated processing times for Alternative 2. 

For the “Provide COTP” function for this alternative as in Alternative 1, the 
assumption was made that all nodes in the Joint ASW C4I Architecture Baseline will 
have the ability to receive the COTP by FY2020. This assumption is based on PEO-C4I 
Masterplan [PEO-C4I Masterplan, 2007: 58] that shows Link-4, Link-11, Link-16 and 
Link-22 all migrating to IP Based waveforms near the year 2020 timeframe. Today there 
are a few of the nodes in the Joint ASW C4I Architecture Baseline such as the F/A-18 
Hornet that does not receive the COTP. We expect by the year 2020 that those nodes will 
have the capability to receive the COTP. Therefore, the associated evaluation measure 
“percent of users with access to the COTP” for this function is expected to be at 100 
percent in FY2020. 

The evaluation measure for the “Fuse ASW Data” function is “minimize data 
fusion processing time.” The value for this measure will be determined by modeling the 
fusion process. 

The evaluation measure for the “Enable Smart Pull and Push of ASW 
Information” function is the “user response time to critical information.” The “Enable 
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Smart Pull and Push of ASW Information” function is a sub function under the “Identify, 
Store, Share and Exchange ASW Data and Information” funetion. The value for this 
measure will be determined by modeling and simulation using an average throughput 
derived from all eommunieation paths listed in Table 11. 

4. Alternative 3 

Alternative 3 represents additional unplanned systems that can be added to the 
systems in Alternative 0 that eould be implemented by FY2020 and signifieantly 
inerease the funetions to “Identify, Store, Share and Exchange ASW Data and 
Information” and “Intereonnect Communication Nodes” by inereasing the bandwidth of 
communications to submarines while operating at speed and depth. In addition these 
systems ean improve the survivability of communieations between nodes as a result of 
the failure of one or more satellite systems due to a system failure or deliberate 
destruction. Figure 35 is a pietorial depiction of the systems expeeted to provide the 
intereonnection between nodes functionality for Alternative 3. As in Alternative 2, the 
evaluation measure “network join time” will be used in an analysis of alternatives. The 
network join time for eaeh eommunieation path is listed in Table 13. 
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Alternative 3 
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Figure 35. Graphical Representation of the Interconnection of 
Communication of Nodes for Alternative 3 

This figure illustrates the communication intercoimectivity of nodes portion of the FY2020 ASW 
C4I Baseline with the addition of High Altitude Aircraft collecting and fusing data and distributing 
the Common Operational Picture to all nodes as described in Alternative 3. 


For the A. 1.1 function, National Aeronautics and Space Administration (NASA) 
is developing a system that has the ability to communicate using x-rays. A technologist 
at NASA’s Goddard space center has developed the world’s first x-ray communication 
system using a Modulated X-ray Source (MXS) [NASA, 2008]. The inventor is 
integrating the system with x-ray optics in the hope of demonstrating the system’s data 
rate of 1 Mbps [NASA, 2008]. The goal is to transmit gigabytes of data per second using 
minimal power [NASA, 2008]. 

Communication via x-rays offers significant advantages to both civilian and 
military space programs. Although currently at a very low technology- readiness 
level, it has the potential to provide high-data rates at low power over vast distances 
in space. In addition, such a communication system could penetrate RF shielding on 
the ground and communicate with hypersonic vehicles during that short period of 
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time when the build-up of heat during reentry blocks traditional communications 
signals [NASA 2008], 

Further research into determining the feasibility or capability of communicating 
with submarines operating at speed and depth needs to be conducted. 

Communication links to submarines are expected to be improved by the use of 
unmanned undersea vehicles [UUV Masterplan, 2004: 1], These vehicles can be 
configured to function as a radio frequency to acoustic gateways. This allows the 
manned submarines to remain submerged and still have the ability to communicate on the 
tactical level. However, the unmanned undersea vehicles currently planned will not 
increase the bandwidth and throughput to a submarine at speed and depth at the levels 
provided by OLC and the possible use of the x-ray communication system using a 
Modulated X-ray Source (MXS). The MXS is expected to increase the data rate of 
communications to 1 Mbps. 

For the functions A.5.1 and A.5.2, high-altitude unmanned aircraft and dedicated 
satellite constellations could be used as an alternative platform to fuse and disseminate 
the common operational tactical picture. The following quote details the NASA’s plans 
for these aircraft. 

In restricted airspace more than 55,000 feet above air force bases and remote 
airstrips in the California desert, NASA this summer will be testing four 
remotely-piloted experimental aircraft. The planes are part of NASA’s 
Environ m ental Research Aircraft and Sensor Technology (ERAST) Program, 
which is developing alternatives to satellites and traditional aircraft as platforms 
for carrying scientific instruments to high altitudes. The experimental aircraft are 
being called ‘atmospheric satellites,’ because they will be able to perform many 
of the functions of orbiting satellites, only at lower altitudes. Project engineers 
aspire to build a plane that will essentially be able to park 55,000 to 60,000 feet 
above a particular location on Earth and remain there for at least six months 
[Clark, 1999]. 

One example of such an aircraft is the solar-powered Helios Prototype being 
experimented with by NASA [Dunbar and Curry, 2008]. Another example is the High 
Altitude Airship being developed by Lockheed Martin [High Altitude Airship, 2008]. 
These aircraft could be designed and configured with the ability to collect, fuse, and 
disseminate data. Since China has demonstrated the capability to destroy satellites, these 
aircraft could serve as the next “high ground” alternatives in the event the current satellite 
constellations were rendered inoperable. Satellites and high altitude aircraft can be 
outfitted with the same systems previously listed in the system connectivity drawings for 
individual nodes Alternative 0, 1, and 2. The advantage of this configuration is increased 
survivability of an overall mission and redundancy. For an unmanned “high ground” Top 
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COTP node alternative, the continuous updating of the Top COTP must be automated 
and not conducted manually as it is in alternatives 0, 1 and 2. Figure 36 illustrates the 
internal node system connectivity representative of Alternative 3. Algorithms will have 
to be developed that can verify that the source track data is indeed coming from the 
sensor associated with the source. Figure 39 is a data flow chart representation of the 
data flow through the systems depicted in Figure 36. 



Figure 36. Internal Node System Connectivity with the Addition of HALO 
Network Wireless Access Points Included for Alternative 2 

This figure shows the internal system connectivity for the systems that are part of the FY2020 
Joint ASW C4I Architecture Baseline that represent the connection of systems of a typical node 
for Alternative 3. 


For function A.5.3, the consolidated network and enterprise services system is 
expected to have evolved far enough to be able to provide wireless connectivity to the 
end users giving the end user the ability to be to connect directly to network services 
provided by satellite and high altitude based communication nodes. There is a 
corporation and its partners that are in the process of creating a wireless broadband super- 
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metropolitan area network (SMAN) for the purpose of interconnecting hundreds of 
thousands of subscribers are multi-megabit per second data rates [The Halo Network, 
2000]. The plan is to offer a ubiquitous access and dedicated point-to-point connection 
through a Federal Aviation Administration (FAA) certified High Altitude Long Operation 
(HALO) aircraft as the hub of the network [The Halo Network, 2000], The aircraft will 
operate above 52,000 feet and will be viewed as a very tall tower or “atmospheric 
satellite” [The Halo Network, 2000], The links will be wireless, broadband, line-of-sight 
covering an area thousands of square miles [The Halo Network, 2000]. Giving all users 
the ability to connect to the network wirelessly and directly to a high altitude connection 
would eliminate the need for extensive shipboard or shore-based network infrastructures 
thereby increasing the overall throughput and speed of operations. This improves the 
distribution of sensor data and the COTP. 

Figure 37 and Figure 38 provide graphical representations of the HALO concept 
that could be applied to military operations. This configuration could add a multi¬ 
megabit network that would have access to all nodes within the battlespace and would 
eliminate many of the relay hops required with satellite systems to receive process and 
distribute the COTP and raw sensor data. This will reduce the need to design and launch 
expensive satellite systems that are not easily recovered and maintained. Based on recent 
demonstrations by the Chinese to take out an in flight weather satellite, a military version 
of the HALO system would be a necessary alternative to existing and planned satellite 
systems [Smith, C; 2007]. In the event one of the satellite systems is disabled, this 
system could be quickly deployed and implemented. A fleet of these aircraft could be 
maintained to support round the clock high altitude network services support to include 
data fusion, COTP distribution and interconnectivity between nodes functionality. 
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Figure 37. Internal Node Configuration of High Altitude Aircraft and 
Graphical representation of Ground, Sea and Air Node Configurations 

This figure shows the internal system connectivity for the addition of the HALO network to the 
FY2020 Joint ASW C4I Architecture Baseline and illustrates a typical node system connectivity 
for the HALO Network and the “High Altitude” central node system connectivity for Alternative 

3. 
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Figure 38. Militarized Version of the HALO Aircraft Network Concept 

This figure is a graphical representation of the communication between nodes using the HALO 
Network concept. The High Altitude Aircraft will function as the Central Processing Hub for 
collecting sensor data and distributing the Top COTP for Alternative 3. 


Table 13 depicts possible improvements that can be realized with the addition of 
the HALO Network. This alternative will provide a network backbone hub or switch 
located at 52,000 feet which can cover thousands of miles of ground area. Each node will 
have the ability to communicate directly with the central high altitude node reducing the 
number of systems that data will have to travel for communications between the various 
nodes forming a star wide area network (WAN) topology. The improvements with this 
alternative are recognized as improvements with the bandwidths available for surface-to- 
surface surface-to-air communications due the HALO network and increased bandwidth 
to the surface-to-sub-surface communications due to MXS. The data processing times 
for collecting, distributing and fusing sensor data and generating and distributing the 
COTP are expected to decrease for Alternative 3. Table 14 is a tabular representation of 
the estimated data process times depicted in Figure 39 for Alternative 3. 
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Figure 39. Data Process Flow Chart for Alternative 3 

This figure shows the flow of sensor and COTP data through the systems represented in Figure 36. 
The estimated processing times are listed in Table 14. 
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Communicat 
ion Path 

System 

Network 

Join 

Time 

(msec) 

Effective 

Throughput 

RF 

Bandwidth 

HALO Network 
Bandwidth 

T ransmit/Recei ve 

Relay 

Delay 

Time 

(msec) 






Uplink 

Downlink 


Surface to 
Surface 
(LOS) 
Network 

HALO 




25 

Mbps 

25 Mbps 


Surface to 

Air 

(LOS) 

Network 

HALO 




25 

Mbps 

25 Mbps 


Surface to 

Surface 

(LOS) 

JTRS 
WNW 
Inc. 5 

2.5 

3 Mbps/ 

# Users 

3 Mbps 



25 

Surface to 

Air 

(LOS) 

JTRS 
WNW 
Inc. 5 

2.5 

3 Mbps/ 

# Users 

3 Mbps 



25 

Surface/Air 
to Sub¬ 
surface 
(LOS) 

MXS 



I Mbps 




SATCOM 

MUOS 

(UHF) 


64 Kbps 

64 Kbps 



500 

TDL 

(LOS) 

Link-16 


8 Kbps 

53.7 Kbps 





Table 13. FY2020 Joint ASW C4I Architecture Baseline “Interconnecting 
Communication Nodes” Data Rates and Relay Delay Times for Alternative 3 

This table shows the bandwidths and effective throughputs of the systems that are part of the 
FY2020 Joint ASW C4I Architecture Baseline that are expected to perform the “interconnection 
between communication nodes” function for Alternative 3 [The Halo Network, 2000; TDL-T 
CDD, 2003; Navy Communications Satellite Program Office, 2004; Ericsson, 2006; Letoumeau, 
2008], 

For the Provide COTP function for this alternative as in Alternative 2, the 
assumption was made that all nodes in the Joint ASW C4I Architecture Baseline will 
have the ability to receive the COTP by FY2020. This assumption is based on the PEO- 
C4I Masterplan [PEO C4I Masterplan, 2007: 58] that shows Link-4, Link-11, Link-16 
and Link-22 all migrating to IP Based waveforms near the year 2020 timeframe. Today 
there are a few of the nodes in the Joint ASW C4I Architecture Baseline such as the F/A- 
18 Hornet that does not receive the COTP. We expect by the year 2020 that those nodes 
will have the capability to receive the COTP. Therefore, the associated evaluation 
measure “percent of users with access to the COTP” for this function is expected to be at 
100 percent by FY2020. 
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The evaluation measure for the “Fuse ASW Data” funetion is “minimize data 
fusion processing time.” The value for this measure will be determined by modeling and 
simulating the fusion process. 

The evaluation measure for the “Enable Smart Pull and Push of ASW 
Information” function is the “user response time to critical information.” The “Enable 
Smart Pull and Push of ASW Information” function is a sub function under the “Identify, 
Store, Share and Exchange ASW Data and Information” function. The value for this 
measure will be determined by modeling and simulation using an average throughput 
derived from all communication paths listed in Table 13. 


Data Process 

System 

Data Process Time 

Interconnect 
Communication Nodes 

All 

5.8 sec 

Unencrypted Sensor 
Data 

ADNS 

100 msec 

[SSC Charleston Fleet Support Branch, 

2008] 

Distribute 

Unencrypted Sensor 
Data 

CANES 

100 msec 

[SSC Charleston Fleet Support Branch, 

2008] 

Fuse Unencrypted 
Sensor Data 

CANES 

100 msec [SSC Charleston Fleet Support 
Branch, 2008] 

Update and Maintain 
COTP (Automatic) 

CANES 

Range: 20 to 120 sec 

[SSC Charleston Fleet Support Branch, 

2008] 

Distribute COTP 

CANES 

100 msec 

[SSC Charleston Fleet Support Branch, 

2008] 

Encrypt COTP 

ADNS 

100 msec 

[SSC Charleston Fleet Support Branch, 

2008] 

Distribute COTP to 
Communication 

Link(s) 

ADNS 

25 msec [SSC Charleston Fleet Support 
Branch, 2008] 


Table 14. FY2020 Joint ASW C4I Architecture Baseline Estimated Data 
Processing Times for Alternative 3 

This tables shows a tabular representation of the data processes illustrated in Figure 39 with the 
approximated processing times for Alternative 3. 
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V. MODEL ALTERNATIVES 


A. MODELING AND SIMULATION PROCESS 

Modeling and simulation was conducted in order to compare alternative solutions 
in an affordable, effective, and repeatable manner. A model is a simplified representation 
of an actual system to increase understanding. Since it is not feasible to compare 
alternatives in their real operating environment, models were built to simplify the 
alternatives into an abstraction of reality in order to mimic the behavior of each 
alternative and promote understanding of the real system. Ultimately, the models were 
built as a strategy to deal with the complexity and uncertainty of the Joint C4IASW 
Architecture. Additionally, the models were built as an analytic framework to quantify 
how well the alternatives performed selected top-ranked functions. Simulation is the 
specific application of a model performed as a method to deal with the dynamic behavior 
of the system and its components. 

The modeling and simulation process, illustrated in Figure 40, consisted of seven 
steps: generating scenarios, selecting the modeling tool and evaluation measures, making 
assumptions, building the models, running the simulations, and analyzing results. During 
this process, a model was created and the simulations were performed by varying the 
inputs in a systematic and logical manner for each alternative. Modeling and simulation 
provided outputs which were used in the analysis of alternatives step to provide the 
stakeholders with recommendations on choosing the best alternative. Further details of 
these seven steps are discussed in the sections below. 



Figure 40. Modeling and Simulation Process 

This figure shows seven actions in the modeling and simulation process. The final result from this 
process is used in the analysis of alternatives step to provide the stakeholders with good 
recommendations on choosing the best alternative. 
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B. SCENARIO AND VIGNETTES OVERVIEW 

The fabricated operational scenario was developed for use in modeling the Joint 
ASW C4I Architecture. The scenario served to bind the architecture to a finite support 
role and helped to focus this capstone project design team which had no prior experience 
with Naval operations. Mission area specific vignettes provided individual 
communication events occurring throughout the course of this Indian Ocean-centered 
scenario. They were developed using a four phased approach: initial preparation of the 
battlespace, extended reconnaissance and surveillance, proactive prosecution, and 
command controlled weapons engagement. To accomplish each of these phases, the 
Undersea Warfare Commander received Joint ASW C4I Architecture support to effect 
movement of data between manned and unmanned sensors, operational platforms, and 
weapons systems focused on ASW. The full 30 day scenario, maps, and vignettes, 
located in Appendix H, outlines the baseline Naval ASW missions, platforms, and 
operational communication paths required to assimilate Naval operations with all blue, 
green and white forces to effectively carry out tasking related to red force identification, 
containment, and destruction. 

The scenario developed for this capstone project is a student exercise and is not 
based on any actual events. This specific scenario was arbitrarily chosen in order to 
frame the modeling and simulation effort in a realistic situation. The scenario began with 
sensing and identification of an underwater missile test being conducted off the coast of 
India in the Bay of Bengal. The President of the United States, upon being briefed on 
national security concerns, ordered the National Command Authority (NCA) to conduct 
ASW specific reconnaissance and surveillance over the area. The theater commander. 
United States Pacific Command (PACOM), was directed to carry out a 30 day 
reconnaissance and surveillance mission. PACOM assigned the mission to the 7th Fleet 
Commander aboard a United States CVN in the South China Sea. The 7th Fleet’s blue 
force task group consisted of an aircraft carrier (50 embarked aircraft (four SH-60 ASW 
helicopters, two E-2 Hawkeye surveillance and 44 fighter and attack (F/A-18) fixed wing 
aircraft)); two guided missile cruisers (two embarked SH-60 ASW helicopters each); one 
destroyer (one embarked SH-60 ASW helicopter); one frigate (one embarked SH-60 
ASW helicopter; and two attack submarines (two embarked unmanned undersea vehicles 
each)). Additionally, the task group was supplemented by United States Navy EP-3, P- 
3C, United States Air Force RC-135 V/W (Rivet Joint) and a RC-8C (JSTARS) aircraft 
stationed in Guam, and one Surveillance Towed Array Sensor System (SURTASS) Low 
Frequency Active (LFA) vessel on station in the Arabian Sea. 
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The blue force commander distributed all available maritime platforms and 
sensors at his disposal to prepare the blue force task group’s over the horizon battlespace. 
Blue force sensor nodes identified small boat and mini-submarine activity transiting the 
Straits of Malacca in Malaysia, but chose not to engage. Later, these units will play a 
role in the scenario. Space-based and joint service air platform sensing activities 
confirmed India’s missile testing. Commercial force shipping operations were confirmed 
in and around India’s major sea port of Vishakhapatnam. Early in the conduct of blue 
force task group operations, a pair of Indian commercial “white force” ships carrying 
sensitive weapon materiel were presumed lost at sea by the Indian government. India 
requested assistance from the United States through diplomatic channels to assist with 
locating the ships. Blue force task group submarines and signals intelligence gathering 
platforms sensed an Indian submarine and aircraft carrier breaking out of port during 
heavy weather. After a series of intra-country coalition communications it was 
determined the two Indian commercial vessels had been hijacked by terrorists using high 
speed boats and mini-submarines. These were the same small maritime contacts made 
earlier and now they are recognized as the red force vessels. The blue force commander 
was directed to change his mission from surveillance of the Indian test firings to tracking 
the terrorists and recovering the stolen weapon materiel. India’s green force went from 
being under blue force surveillance to a strong coalition partner coordinating naval 
operations to locate and engage terrorists and lost cargo. Complete order of battle 
information is provided in Table 15. 
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Platforms 

Blue Force 

Green Force ' 

White Force 


Surface Ships 

1 Aircraft Carrier (CVN) 

1 Aircraft Carrier (CVN) 

2 Merchant Ships 

2 Small Go Fast Boats 


2 Guided Missile Cruiser (CG) 

2 Guided Missile Destroyer (DDG) 

1 Surveillance Towed Array Sensor 

System (SURTASS) 

1 Guided Missile Cruiser (CG) 


Aircraft 





Land Based 

Ship Based 

1 Joint Surveillance & Target Attack 

Radar System (RC-8C (JSTARS)) 

1 Rivet Joint (RC-135VA¥) 

1 Electronic P-3 (EP-3) 

1 P-3 Orion 

30 Strike Attack (F/A-18) 

2 Surveillance (E2D Hawkeye) 

10 ASW Helicopter (SH-60) 

1 Electronic P-3 (EP-3) 

1 P-3 Orion 

15 Harrier (AV-8) 

6 ASW Helicopter 



Submarines 

1 Nuclear Attack (SSN 688) 

1 Nuclear Attack (Kilo Class) 


2 Miniature Submarines 


1 Nuclear Attack (SSN 774) 

1 Nuclear Attack (SSN 774) 



Shore C2/C4I Sites 






1 Naval Operational Processing 

Facility (NOPF) 

1 NCTS Bahrain 

1 Communications Facility, Cochin 

1 Communications Facility, 

Vishakhapnat 




Table 15. Scenario Order of Battle 

This table displays all platforms of United States Blue Force; India’s Green Force; hijacked White Commercial Maritime Forces, and Adversarial Red 
Forces portrayed and participating in the operational scenario. 
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The combined blue and green maritime coalition force acted quickly to identify 
and locate the red force high speed craft and mini-submarines using a well coordinated 
and communicated engagement plan. Fixed wing and rotary wing aircraft contributed to 
sensing the surface and subsurface enemy targets and ensured decisive weapons 
engagement of the enemy along with blue and green coalition force surface and 
submarine platforms. The engagement culminated in the return of the weapon materials 
and the confiscation of terrorist vessels. White commercial forces were sunk by the 
enemy. 

C. MODELING AND SIMULATION APPROACH 

The goal of this phase was to model and run simulations of a blue force ASW task 
group’s C4I network. Modeling and simulation served as the mechanism for quantifying 
each alternative’s performance as it relates to the key evaluation measures. “Key issues 
in simulation include acquisition of valid data source information about the system, a 
selection of key characteristics, the use of simplifying approximations and assumptions 
within the simulation, and reliability and validity of the simulation outcomes” 
[Universiteit Leiden, 2008]. Alternative solution performance characteristics served as 
inputs for the model. Models were run for the blue force task group’s FY2020 Joint 
ASW C4I Architecture Baseline (Alternative 0) and three additional alternative solutions. 

1. Tool Selection 

To build the performance models for each of the alternatives, the modeling tools 
CORE, NSS-21, EXTEND, and ARENA were studied. Each of these tools has its 
advantages and limitations. For example, CORE can provide the capability to simulate 
behavior models, such as functional flow block diagrams, in order to analyze the dynamic 
performance and behavior of a system’s functional model. It can also be used to verify 
system design to clarify breakpoints and aid the systems engineering process [Vitech 
Corporation, 2000: 1]. Unlike CORE, NSS-21 can be used to support multi-warfare 
mission area analysis and operational commanders in developing and analyzing 
operational courses of action. NSS-21 is an object-oriented Monte Carlo modeling and 
simulation tool and was developed to analyze operational metrics. However, it was not 
chosen because it provides coarse and sometimes incorrect assumptions of the underlying 
network. As for EXTEND and ARENA, these two tools can be used to model any 
system or process. Their dynamic modeling capabilities can be utilized to help 
organizations answer questions about how an existing or a proposed system will perform. 
In the end, EXTEND was chosen over ARENA because EXTEND allows the sequence 
of simultaneous events to be modified by adjusting graphical position while ARENA 
does not. This was a very important feature in this complicated architecture because its 
flexibility allowed for easy modification of the model based on the alternatives. 
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EXTEND has unique capabilities that enabled the building of performance models for the 
Joint ASW C4I Architecture. Additional details of the EXTEND model that was built are 
provided in the sections below. 

2. Evaluation Measures for Modeling and Simulation 

The value hierarchy shown in Figure 17 has two distinct branches, functional and 
non-functional. The focus of the modeling and simulation was to model and measure the 
evaluation measures of the functional branch. There were six critical evaluation 
measures associated with the five top ranked functions, identified by the stakeholders as 
the most important and shown in Table 1. From these six evaluation measures, it was 
easy to quantify the performance of three of them - latency, throughput, and data fusion 
time - through modeling and simulation. The remaining three evaluation measures - the 
percentage of users with access to COTP, time to interconnect, and time to pull and push 
ASW information - were analyzed through research and offline evaluation, which is 
described in detail in the alternatives generation section. 

Since the scenario for each alternative was unchanged and only the performance 
parameters were changed, the selected evaluation measures were captured in a systematic 
fashion. Once the data for latency, throughput, and data fusion processing time was 
collected, statistical analysis was performed and results were used in the next step of the 
process, analysis of alternatives. 

3. Assumptions 

Each C41 node within the baseline system is mobile resulting in ever changing 
distances between nodes. Range changes were not considered in these modeling and 
simulation activities. Ranges were assumed to be static with no platform position 
changes in latitude, longitude, or elevation. The blue force ASW task force required 
communications flexibility using all line-of-sight and beyond line-of-sight 
communication tools available to each communicating platform. However, since it 
would be too complex to model all of the communication paths, it was decided to focus 
on the preferred communication paths without a degraded mode analysis. Therefore, for 
line-of-sight, surface-to-surface, and surface-to-air, the preferred communication path is 
wideband network waveforms. For surface to sub-surface, it is communications at speed 
and depth. For tactical data links, it is Link-16, and for satellite communications, it is 
MUOS. 

Key modeling and simulation objectives were to determine which alternative 
solution most reduced latency, reduced data fusion time, and increased data throughput. 
Thus, time lag of data receipt and the number of required hops between transmitting and 
receiving locations are directly related to physical distance and geographic positioning 
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between blue foree ASW task group eommunieators and the number of communieations 
relays and nodes needing connection to achieve positive communications. 

4. Generic Model Description 

In order to aid the decision making phase, the model was built based on a kill 
chain which includes three components: detect, control, and engage. The kill chain was 
adopted to establish a clear set of functions that the system of systems must perform. 
Within this model, the inputs and outputs for each of these functions were consistent with 
the IDEFO and functional flow block diagram developed during needs analysis. The 
purpose of the model was to demonstrate and quantify how effectively the architecture 
performed the kill chain, from detect to engage, for each alternative. The top-level 
diagram of the model is shown in Figure 41. Detailed explanations on the model are 
provided in paragraphs below. 



Figure 41. Top-Level Diagram of Model 

This figure shows the top-level diagram of the model, which is based on a kill chain. The inputs 
and outputs for each of these functions are based upon IDEFO and functional flow block diagrams. 

a. Detect 

Detection was the first phase of the kill chain in the model. Using 
EXTEND, each platform was modeled separately. Within the detect phase, contact 
reports were generated in the model based on the scenario and fed into the simulated 
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system. Each of these contact reports included the detection time, identification, and 
location of a track as well as the data size. Then, depending on the platform’s location 
and communication equipment, an off-ship path of either line-of-sight or beyond line-of- 
sight would be selected to transfer these contact reports into the control area. As 
mentioned in the alternatives generation section, the scope did not include degraded or 
overflow operations because it was assumed that the Navy will be migrating from 
numerous stove-piped solutions to joint solutions. So, while other communication paths 
will likely exist in 2020, the focus was on preferred communications paths that are 
designed to provide superior performance and joint interoperability. 

Depending on the selected off-ship path and its bandwidth, a capacity 
delay and a physics delay were applied. Capacity delay was determined by dividing the 
size of data input with the bandwidth. Physics delay was the latency of the 
communication system such as satellite communications or tactical links. The values for 
bandwidth and latency came from Table 7, Table 9, Table 11, and Table 13 in the 
alternatives generation section. Depending on the alternative, different values would be 
used. Also, based on this knowledge from this capstone project design team’s work on 
data collection, the size of data input was randomly selected between the ranges of 50- 
500 kilobits. Finally, the contact reports from all of the platforms were transferred into 
the control area where data fusion would be performed. Based on each alternative and its 
description in the alternatives generation section, time lag of data receipt and the number 
of required hops between relay locations were applied into the model. The detect section 
of the model is shown in Figure 42. 


DETECT 


ASW Sensor Tasking 


Contact Reports 
From Each 
Platform Transfer 
Into Control Area 
Through LOS or 
BLOS With 
Capacity and 
Physics Delay 
applied. 


ASW Sensor Data 


Figure 42. Detect Section of the Model 

This figure shows the detect section of the model. The input and output for this function are based 
upon IDEFO and functional flow block diagrams. 
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b. Control 

As indicated previously, the Joint ASW C4I Architecture Baseline model 
was developed in EXTEND using the functional hierarchy, IDEFO, extended functional 
flow block diagrams, and information from the baseline of interconnecting links. As 
shown in the IDEFO A-1 diagram in Figure 11, various types of data such as ASW sensor 
data, meteorological and oceanographic data, computer attack data, physical attack data, 
electronic attack data, weapon status data, user commands, and user requests were 
generated and implemented in EXTEND. Once all the different types of data were 
generated from various sources, it entered the control section of the kill chain. 
Furthermore, the control section was separated into four interconnecting modules: 
information operation module; fuse data module; provide COTP module; and identify, 
store, share, and exchange ASW data and information module. The control section of the 
model is shown in Figure 43. 



Figure 43. Control Section of the Model 

This figure shows the control section of the model. The inputs and outputs for each of these 
functions are based upon IDEFO and functional flow block diagrams. 


(1) Information Operation Module 

As described by the perform information operations function, the 
Joint ASW C4I Architecture provides a secure and protected network. Therefore, the 
goal of this module was to remove all of the possible threats such as computer attack, 
physical attack, and electronic attack from entering the Joint ASW C4I Architecture. The 
assumption was made that 80% of the threats will be defeated prior to entering the Joint 
ASW C4I Architecture; however, 20% will enter the Joint ASW C4I Architecture. If the 
threat entered the Joint ASW C4I Architecture, then additional resources were used to 
respond to the threat, which caused additional delay in the processing of ASW sensor 
data, METOC data, and ASW weapon data. Once all the threats were completely 
defeated and removed, ASW sensor, METOC, and ASW weapon data was passed 


145 
























through to the ASW data fusion module. The information operations module is shown in 
Figure 44. 



Figure 44. Information Operations Module of the Model 

This figure shows the information operations module of the model. The inputs and outputs for 
each of these functions are based upon IDEFO and functional flow block diagrams. 

(2) ASW Data Fusion Module 

Since the focus of the model was to capture latency, bandwidth, 
and data fusion processing time rather than accuracy or quality of the fused data, the 
assumption was made that ASW Data Fusion functionality will be treated as a “black 
box.” Therefore, no algorithms, codes, or blocks were implemented to show that contact 
reports from sensors were fused to create a track report. However, the processing time 
for a particular contact report to be fused was captured. The expected performance 
parameters of processing time from Net-Enabled Command Capability (NECC) and 
Consolidated Afloat Network Enterprise Services (CANES) were utilized in the 
EXTEND model, and the data fusion processing time was captured for each event 
generated by the scenario. 

ASW sensor data, ASW weapon data, and METOC data were 
combined into single outputs, shown in Figure 45. This single output is consistent with 
the IDEFO and extended functional flow block diagrams that were constructed during the 
functional analysis phase. Fused data was then passed through to the provide COTP 
module. 
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Figure 45. Data Fusion Model 

This figure shows the ASW data fusion module of the model. The inputs and outputs for each of 
these functions are based upon IDEFO and functional flow block diagrams. 


(3) Provide COTP Module 

The COTP is used for situational awareness, which took its inputs 
from the data fusion function. Single track information, in the form of ASW fused data, 
received from the data fusion module was inserted into a central location which kept 
information for multiple tracks. The tracks being stored here were verified to see 
whether they were current. Those tracks that were engaged and destroyed would be 
deleted. If the tracks were engaged and not destroyed, the track was kept until it was 
destroyed. The COTP gave the user a visual representation of all tracks that provided 
information on both friendly tracks and hostile tracks. The provide COTP module is 
shown in Figure 46. 
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Track Storage and 

COTP 



Verification 



Figure 46. Provide COTP Module 

This figure shows the provide COTP module of the model. The inputs and outputs for each of 
these functions are based upon IDEFO and functional flow block diagrams. 

(4) Identify, Store, Share, and Share ASW Data and Information 

This function included all the actions necessary to store, publish, 
and exchange information and data. Data was appropriately identified, labeled, and 
placed into a repository which was shared by the engage portion of the model. 
Information on the tracks that the user was interested in utilizing for engagement was 
given a priority to be sent to the engaged elements. For a hostile track, based on its 
information, the appropriate weapon was selected for engagement. When the weapon of 
choice was out of its inventory, the system automatically selected the next appropriate 
weapon. Figure 47 represents information going in and out of the identify, store, share, 
and exchange ASW data and information module. 

When the user had no communication with the system, automation 
was utilized to let the system select the weapon of its choice, again keeping the inventory 
status in mind. Finally, information was passed to the engage portion for engaging the 
track after the system compared the weapon selection criteria for a track against the 
weapon inventory. 
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Figure 47. Identify, Store, Share and Share ASW Data and Information 
Module 

This figure shows the identify, store, share, and exchange ASW data and information module of 
the model. The inputs and outputs for each of these functions are based upon IDEFO and 
functional flow block diagrams. 


c. Engagement 

The engage portion of the model was developed in aceordanee with how a 
typieal weapon engagement is executed and the kinds of outputs it will provide to the rest 
of the kill chain. Some of the characteristics of a weapon engagement considered were 
the following: receive a weapon task, launch a weapon, guide a weapon to target, provide 
weapon inventory, and provide a kill evaluation of the target track. To simplify the 
system model, it was assumed that the receive ASW information function is responsible 
for providing the ASW weapon tasking to the weapons. The weapon tasking was made 
available through the receive ASW information function in the Joint ASW C4I 
Architecture, which is an internal network function and is similar to retrieving a piece of 
mail from your mailbox. The tasking provided information regarding the weapon type 
and communication node. A majority of the characteristics of a weapon engagement 
were demonstrated; but the weapon launch, guidance, and target intercept characteristics 
were simplified in order to keep the model within the scope of the project. The inputs 
and outputs of the engagement portion can be viewed in Figure 48. 
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Figure 48. Engage Section of the Model 

This figure demonstrates the input and output of the engage portion. The weapon tasks are 
received from the control portion. These tasks are interpreted and a weapon is engaged. 


Prior to engaging a target track, the proper communication path needed to 
be selected to allow the weapon tasking to reach a designated platform on which the 
preferred weapon resided. In keeping the scope of the engagement at a minimum, the 
detailed launch sequence was not modeled. The overall weapon engagement, kill 
evaluation, and intercept were demonstrated through various probability and delay 
functions. The delays contained minimal times to represent a weapon launch sequence, 
while the probabilities represented the actuality of a weapon intercepting the target track. 
Depending on the probability of weapon intercept, a kill or no kill status was provided to 
the control architecture. Next, an evaluation of weapon inventory was modeled by 
decrementing the number of weapons available every time a particular weapon was 
selected and launched. The status for kill evaluation, weapon inventory, and target 
engaged were then provided to the control section for further evaluation. 

5. Modeling Alternatives 

For all four alternatives, the baseline model is used as a skeleton to start the 
modeling, specifically the detect and engage functions of the baseline model. 
Furthermore, the configuration of the users’ inputs and the insertion of a scenario with 
multiple tracks were also common among the alternatives. The alternatives differed from 
each other in terms of the predicted performance of the communication systems and the 
additions of different sensors. Thus, based on these differences in communication, the 
models for each alternative were constructed. Within each model, the inputs for latency 
for line-of-sight, beyond line-of-sight, and common operational and tactical picture were 
pulled from Table 7 through Table 14 in the alternatives generation section. 

Furthermore, for the model to represent a realistic environment, random normal 
distribution generators of time for information being inserted from outside threats and 
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from sensors within the system were added into the control section. Tolerance levels 
were set for each distribution generator so that the outputs being generated for each of the 
runs for each alternative are not controlled. 

D. MODELING AND SIMULATION RESULTS 

As stated previously, the evaluation measures that were modeled were throughput, 
latency, and data fusion time. To effectively model these evaluation measures, each of 
the four alternatives was simulated ten times in the operational scenario model. During 
each one of these simulations, one hundred data points were collected for each of the 
three evaluation measures. Overall, this resulted in one thousand data points for each 
evaluation measure for every one of the four alternatives. The amount of data captured 
with the simulations allowed the mean to be calculated for each evaluation measure for 
each alternative. The data was also used to construct visual statistical techniques such as 
histograms to demonstrate the frequency distribution of the data and to aid in the 
determination of any skewness or outliers in the data. 

1. Throughput Results 

The throughput evaluation measurement represented the amount of data, in 
kilobits per second, that could flow through any particular platform based on the 
allowable bandwidth, size of the data, and time. It is important to maximize throughput 
because this allows more information to flow through the system and ultimately speeds 
up the kill chain. In the Joint ASW C4I Architecture model, the throughput measurement 
was taken for every platform from the operational scenario. The throughput 
measurement was collected at a node that was located at the output of contact tracks and 
after the capacity and physical delays as part of a feedback loop. This is all depicted in 
Figure 49. As seen in this figure, there were numerous platforms which required multiple 
communication jumps to reach the control portion of the kill chain. These platforms 
were modeled with more capacity and physical delays as shown in platform B in the 
figure. 
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Figure 49. Throughput Measurement Block Diagram 

The figure depicts the nodes used to obtain the throughput measurements in the various 

alternatives. 

The configuration of the model allowed for simple adjustments to the capacity 
and physical delays. After ten simulations were run for each alternative and data was 
recorded, the throughput mean for each alternative was calculated. For the throughput 
measurement, every alternative had approximately one thousand data points to calculate 
the throughput mean. The calculated mean for Alternative 0,51.292 kilobits per second, 
was the lowest throughput mean when compared to all the alternatives as viewed in Table 
16. The mean for Alternative 2, 58.855 kilobits per second, was the highest of all the 
alternatives. 


Measurement 

Alto 

Alt 1 

Alt 2 

Alts 

Throughput (kbps) 

51.292 

53.930 

58.855 

58.155 


Table 16. Average Throughput Comparison of all Alternatives 

This table shows the mean of all the ten runs of all the alternatives. It can be observed from the table 
that Alternative 2 had the largest throughput mean. 


Histograms were constructed in order to better comprehend the behavior of the 
data, such as the one found in Figure 50 for Alternative 0. The histogram provided a 
visual depiction of Alternative O’s frequency distribution of the throughput data. The 
figure shows that the data for Alternative 0 was positively skewed. This phenomenon 
was a result of numerous outliers that were generated due to certain platforms having 
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longer delay times and various jumps to get their sensor data to the control function. The 
phenomenon was consistent with the rest of the alternatives as seen in Appendix I. 
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Figure 50. Throughput Measurement for Alternative 0 

This figure shows the histogram of the throughput measurement for Alternative 0. The mean of all 
the data was calculated and used in the average throughput comparison between all the alternatives. 

2. Latency Results 

The latency evaluation measurement represented the internal processing time of 
data. It is important to minimize latency because this increases the flow of information 
through the system and ultimately speeds up the kill chain. In the Joint ASW C4I 
Architecture model, the latency measurement was taken at the control section of the 
system because all the data processing of the operational scenario occurred at this point. 
The latency measurement was obtained by allocating timers at particular locations in the 
model to obtain the time when a track entered the control section and when it exited the 
section, as displayed in Figure 51. 
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Figure 51. Latency Measurement Block Diagram 

The figure depicts the timers used to obtain the latency measurements in the various alternatives. 


The configuration of the model allowed for a complete measurement of latency 
from start to finish within the Joint ASW C4I Architecture. After ten simulations were 
run for each alternative and data was recorded, the latency mean for each alternative was 
calculated. Every alternative had approximately one thousand data points to calculate the 
latency mean. The calculated mean for Alternative 3, 680.160 milliseconds, was the 
lowest latency mean when compared to all the alternatives as viewed in Table 17. The 
mean for Alternative 0, 1334.161 milliseconds, was the highest of all the alternatives. 


Measurement 

Alto 

Alt 1 

Alt 2 

Alts 

Latency (ms) 

1334.161 

1205.027 

685.560 

680.160 


Table 17. Latency Time Averages for all Alternatives 

This table demonstrates the averages of all the ten runs of all the alternatives for the latency 
measurement. It can be observed from the table that Alternative 0 had the largest latency mean. 


Similar to the throughput measurement, histograms were constructed such as the 
one found in Figure 52 for Alternative 3 to better comprehend the behavior of the data. 
The histogram provided a visual depiction of Alternative 3’s frequency distribution of the 
latency data. It can be observed that the data for Alternative 3 was bimodal. This 
phenomena was the result of two variables: the delayed sensor data received from 
platforms in the sensor portion and the relative distance of both timers. The phenomenon 
was consistent with the rest of the alternatives as seen in Appendix 1. 


154 












































Latency Alt3 



Latency Time (ms) 


Figure 52. Latency Time Histogram of Alternative 3 

This figure shows the histogram of the latency measurement for Alternative 3. The average of all 

the data was calculated and used in the average latency comparison between all the alternatives. 

3. Data Fusion Results 

The data fusion evaluation measurement represented the amount of time to fuse 
various sensor, weapon, and METOC data. It is important to minimize data fusion time 
because this increases the flow of information through the system and ultimately speeds 
up the kill chain. Data fusion was considered a black box within the Joint ASW C4I 
Architecture model, that consisted of multiple delay functions which demonstrated the 
data fusion processing time found in various systems. As shown in Figure 53, the 
measurement for data fusion processing was obtained by incorporating a timer after all 
the inputs from ASW sensor data, ASW weapon data, and METOC data were fused and 
sent to the COTP. 
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Figure 53. Data Fusion Measurement Block Diagram 

The figure depicts the timer used to obtain the Data Fusion Measurements in the various 
alternatives. 


As with the throughput and latency measurements, the data fusion processing time 
measurement was obtained through simulation of the Joint ASW C4I model. The model 
was simulated ten times for each alternative and data fusion processing time was 
captured. The data fusion processing time mean for each alternative was calculated. 
Every alternative had approximately one thousand data points to calculate the data fusion 
processing time mean. The calculated mean for Alternative 3, 299.720 milliseconds, was 
the lowest data fusion processing time mean when compared to all the alternatives as 
viewed in Table 18. The mean for Alternative 0, 702.395 milliseconds, was the highest 
of all the alternatives. 


Measurement 

Alto 

Alt 1 

Alt 2 

Alts 

Data Fusion Processing Time (ms) 

702.395 

540.139 

299.823 

299.720 


Table 18. Fusion Time Averages for all Alternatives 

This table demonstrates the averages of all the ten runs of all the alternatives for the data fusion time 
measurement. It can be observed from the table that Alternative 3 had the lowest data fusion time 
average. 

To better comprehend the behavior of the data, histograms were constructed such 
as the one found in Figure 54 for Alternative 1. The histogram provided a visual 
depiction of Alternative I’s frequency distribution of the data fusion processing time. It 
can be observed that the data for Alternative 1 was unimodal in nature and had a normal 
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distribution. This phenomenon was consistent with the rest of the alternatives as seen in 
Appendix I. 


Data Fusion Alt1 


>. 

O 

c 

o 

3 

O' 

o 




ffli. 


35 
30 
25 
20 
15 
10 
5 
0 

^ ^ ^ ^ ^ ^ ^ 

Data Fusion Time (ms) 




Tinrhn 


Figure 54. Fusion Time Histogram for Alternative 1 

This figure shows the histogram of the data fusion time measurement for Alternative 1. The 
population mean of all the data was calculated and used in the average data fusion time comparison 
between all the alternatives. 


E. MODELING AND SIMULATION SUMMARY 

The modeling and simulation phase of the Joint ASW C4I Architecture utilized a 
simple operational scenario and performance models, built in EXTEND, to quantify the 
performance of each alternative. This was accomplished through simulation to generate 
data related to evaluation measures developed in the value system. The evaluation 
measures identified for modeling and simulation were throughput, latency, and data 
fusion time. The values for throughput and latency, which were inputs into the model, 
came from the alternatives generation section. These values were acquired through 
extensive research of fielded and planned systems. Furthermore, the values for data 
fusion times were derived from the aforementioned data. A summary of the results that 
were inputs to the analysis of alternatives are displayed in Table 19. 


Measurement 

AitO 

Ait1 

Ait 2 

Alts 

Throughput (kbps) 

51.292 

53.93 

58.855 

58.155 

Latency (ms) 

1334.161 

1205.027 

685.56 

680.16 

Data Fusion Processing Time (ms) 

702.395 

540.139 

299.823 

299.72 


Table 19. Modeling and Simulations Results 

This table demonstrates the averages of all the ten runs of all the alternatives for the throughput, 
latency, and data fusion measurements. 
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Overall, confidence is high in the modeled results because the input values were 
traceable through the systems engineering process and represent a close approximation of 
the actual performance. While the model provides insight to difficulties and expectations 
for networks supporting line-of-sight and long haul communications, it does not 
accurately describe the multitude of two way electronic signals traveling between the 
ASW fleet’s communications suites. More explicit data inputs would improve the 
understanding of the Joint ASW C4I Architecture’s ability to interoperate. However, this 
would require the use of far more robust modeling techniques but would permit the 
operational user to identify and quickly enter new C4I tools as they continually improve 
operational data transmission means. The C4I network architecture modeled here 
identifies problems of latency, environmental and distance constraints, and more 
importantly demonstrates the extreme level of difficulty for multiple frequency ASW 
operations on a global scale. 
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VI. LIFE CYCLE COSTS 


A. LIFE CYCLE COST OVERVIEW 

Life cycle cost estimation (LCCE) for the Joint ASW C4I Architecture is an 
important multi-faceted contributor of the systems engineering process. LCCE, when 
sufficiently detailed, enables high level decision makers to determine affordability, 
analyze alternatives, conduct cost versus performance tradeoffs, and establish program 
cost goals. A conscious decision was made to limit the scope of the life cycle costs for 
this project to research and development, production and installation, operation and 
support, and disposal costs. Ground truth information was sought out from program 
executive offices to better itemize future C4I architecture costs. The life cycle cost 
summary provided a solid basis for recommending the best alterative addressing the war 
fighter’s needs. 

B. COST ESTIMATION APPROACH 

1. Scope 

LCCE was developed for each of the four alternatives described in the alternatives 
generation section. The cost categories addressed are research and development, 
production and installation, operation and support, and disposal. The LCCE is for a 
single United States Navy ship and only shows costs to address the functional gaps 
identified in the alternatives generation section. Table 6. LCCE does not include costs 
for the coalition or joint partners to deploy the Joint ASW C4I Architecture. A separate 
analysis for costs would have to be carried out for coalition partners as their functional 
gaps would be different depending on their specific implemented architecture. 

2. Assumptions 

Multiple DoD infrastructure programs of record contribute to the Joint ASW C4I 
Architecture. The components of a joint net-centric architecture are the space segment 
such as SATCOM - TSAT and CBSP; terrestrial infrastructure segment such as gateways 
for space segments, internet gateways, and line-of-sight links such as microwave, fiber, 
JTRS; network management segment; and the local node segment that includes hosted 
service oriented architecture applications and common computing environment. A nine 
year life cycle is assumed based on obsolescence of technology in software, hardware, 
and architecture. The individual programs of record within the four segments have their 
own life cycles. This life cycle cost estimate, provided below, only applies to the local 
segment for a notional Navy ship. This is a simplification of the problem at hand to make 
it manageable. The life cycle cost for Alternatives 0, 1, and 2 covers the common 
computing infrastructure, wide band internet protocol based communications, and service 
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oriented architecture for the Joint ASW C4I Architecture. Alternative 3 adds HALO and 
HAA platforms to the joint net-centric architecture. Research and development costs are 
incurred whether the capability is deployed on one ship or the entire fleet. Man-day 
costs, percentage of time an operator works on the system, mean time to repair, logistical 
delay time, maintenance delay time, number of operators and maintainers, and number of 
repair actions per system per year are included in the overall operation and support costs. 
Maintenance is restricted to be replacement of defective items. 

3. Cost Breakdown Structure 

A cost breakdown structure was developed as an aid to the life cycle cost analysis. 
The cost break down structure is displayed in Figure 55. The cost breakdown structure 
was built to cover activities and associated costs which include research and 
development, production and installation, operation and support, and disposal. The CBS 
guided the collection of data from the individual program offices. 
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Figure 55. Cost Breakdown Structure 

This figure shows the cost breakdown structure used to estimate Joint ASW C4I Architecture 
costs. Cost data for each of the sub-elements was collected and rolled up to the top level 
categories: Research and Development, Production and Installation, Operation and Support and 
Disposal. 
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Research and development costs are costs related to program management; 
concept refinement; trade studies; prototyping - fabrication and assembly, engineering, 
integration, testing, and test equipment; training; and initial spares associated with 
prototypes and engineering development models. Research and development costs for 
the Joint ASW C4I architecture are recurring costs. Research and development provides 
new capabilities through continuous investment in each new increment and also 
addresses the need to reduce manpower requirements through increasing levels of 
automation and distance support. Research and development costs for Alternative 0, 1, 
and 2 is a mix of integration costs for commercial of the shelf software and hardware and 
development and integration of special purpose built software and hardware. Research 
and development costs for Alternative 3 are higher as this capability requires 
development and maturation of new technology. 

Production and installation costs cover production and deployment costs from the 
initial production units through full deployment. These costs include program 
management, hardware and software, engineering, special equipment needed in the 
production and deployment, training, technical publication, and initial spares and repair 
parts. It also includes site construction, operation, and maintenance costs as needed. 
Installation of systems on a ship is an expensive effort as compared to installation of 
systems at a shore site. Installation for future ASW C4I will be enhanced through 
complete staging of modular systems at pre-configuration facilities. The modular system 
will be fully assembled and tested in an integration facility which duplicates the final 
environment down to cable lengths. This will reduce costs and greatly simplify 
installation and check out of a system on ship. Production and installation cost for 
Alternative 3 are higher due to the need for ground control stations which are required for 
management and control of these platforms. 

Operation and support costs are all costs, direct or indirect, that pay for personnel, 
supplies, equipment, software and hardware maintenance, and training. The costs cover 
the time from initial deployment to end of systems life. Operation and support costs are 
the dominating costs over the life of a ship. The future ASW C4I architecture will be 
designed to reduce operation and support costs through “smart equipmenf ’ design, 
simpler modular equipments that are repairable on board ships, tracking equipment life 
history for condition based maintenance, and automated diagnostics for isolating 
problems and directing repair. Maintenance concept is limited to replacement of 
defective parts and or whole units. Operation and support costs for Alternative 3 are 
much higher than any of the other alternatives, because Alternative 3 requires ground 
control stations and personnel to man it. Costs may be reduced by sharing the cost of this 
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platform with other unmanned vehicles. Yearly operation and support costs for the 
alternatives are assumed to be fourteen percent of procurement cost. 

Disposal costs are costs associated with removing the system from its deployed 
environment and its proper disposal. This includes demilitarization, disassembly, 
hazardous material processing and decontamination of site and equipment, transportation, 
and safety precautions. Disposal costs can be as simple as de-installing an automated 
information system or as complex and costly a task as proper disposal of nuclear waste. 
The wide variability of costs associated with disposal requires serious consideration up 
front. Disposal costs for future ASW C4I systems are expected to increase as 
environmental laws are tightened and global awareness of environment grows. The use 
of solar panels and fuel cells increases the costs of disposal for Alternative 3. 

C. COST DATA COLLECTION 

Program Executive Offices (PEO) are the DoD’s acquisition arms that provide 
mission capabilities to the fleet. PEO Integrated Warfare Systems (IWS) provides the 
combat systems, PEO Littoral and Mine Warfare (LMW) provides mission systems that 
support LMW, and PEO C4I is responsible for the acquisition of the communication links 
such as tactical data links, line-of-sight, and beyond line-of-sight communications for the 
Joint ASW C4I Architecture as well as ship wide common computing environment, 
signal exploitation system, command and control systems, meteorological systems, 
cryptography hardware, and crypto logical systems. The C4I cost data was collected 
from the PEO C4I program offices through interviews with Mr. Roland Feghali (PMW 
120), Mr. R. Miguel Heard (PMW 150), Mr. Baasit Saijid (PMW 160), and Mr. Joel 
Cabana (PMW 170) [Feghali, 2008; Heard, 2008; Saijid, 2008; Cabana, 2008]. Cost data 
was requested from PEO IWS but was never received. No cost data was requested from 
PEO LMW. One reason was the hesitancy of each program to share what is considered 
sensitive cost data. The fidelity of data as well as the time span addressed varies greatly 
by source; sometimes the costs were ship construction Navy costs and sometimes the 
costs were research and development costs that were provided for only two or three cost 
categories over future years defense plan. Most of the data was at the level of individual 
program offices within the PEO. Operation and support costs were assumed to be 
approximately fourteen percent of procurement cost per year for commercial off the shelf 
products (hardware and software). This is a nominal operational and maintenance cost 
and is consistent with operation and support costs currently incurred in similar programs 
across PEO C4I and DoD. 


163 



Table 20 summarizes the preliminary life eycle eost estimate for each category. 
The costs are in millions of dollars and have been deflated using DoD guidelines for 
future years. The table shows costs of each alternative starting from relative year one of 
the program out to year nine. The total cost for Alternative 0 is $95.09M, Alternative 1 is 
$121.1 IM, Alternative 2 is $136.92M, and Alternative 3 is $854.60M. 
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Totals 


Year 




1 

2 

3 

4 

5 

6 

7 

8 

9 




$M 

$M 

$M 

$M 

$M 

$M 

$M 

$M 

$M 

$Million 

Alto 

R&D 

6.14 

10.14 

8.92 

16.08 

18.21 

10.55 

0.00 

0.00 

0.00 

70.04 


P&l 

0.00 

0.00 

7.19 

0.00 

0.00 

0.00 

10.16 

0.00 

0.00 

17.35 


O&S 

0.00 

0.00 

0.00 

1.01 

1.07 

1.15 

1.27 

1.42 

1.63 

7.54 


Disposal 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.15 

0.15 


Totals 

6.14 

10.14 

16.11 

17.09 

19.27 

11.70 

11.43 

1.42 

1.78 

95.09 

Altl 

R&D 

10.76 

14.29 

13.12 

20.22 

22.43 

14.86 

0.00 

0.00 

0.00 

95.67 


P&l 

0.00 

0.00 

7.30 

0.00 

0.00 

0.00 

10.32 

0.00 

0.00 

17.62 


O&S 

0.00 

0.00 

0.00 

1.02 

1.08 

1.17 

1.29 

1.44 

1.65 

7.66 


Disposal 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.15 

0.15 


Totals 

10.76 

14.29 

20.42 

21.24 

23.51 

16.03 

11.60 

1.44 

1.81 

121.11 

Alt2 

R&D 

13.86 

18.19 

14.62 

20.92 

22.43 

14.86 

0.00 

0.00 

0.00 

104.87 


P&l 

0.00 

0.00 

9.20 

0.00 

0.00 

0.00 

13.00 

0.00 

0.00 

22.20 


O&S 

0.00 

0.00 

0.00 

1.29 

1.36 

1.47 

1.62 

1.82 

2.09 

9.65 


Disposal 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.20 

0.20 


Totals 

13.86 

18.19 

23.82 

22.21 

23.79 

16.33 

14.62 

1.82 

2.28 

136.92 

A Its 

R&D 

51.65 

59.51 

53.47 

61.93 

62.73 

55.07 

0.00 

0.00 

0.00 

344.36 


P&l 

0.00 

0.00 

146.20 

0.00 

0.00 

0.00 

206.59 

0.00 

0.00 

352.79 


O&S 

0.00 

0.00 

0.00 

20.47 

21.66 

23.38 

25.75 

28.92 

33.14 

153.32 


Disposal 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

4.13 

4.13 


Totals 

51.65 

59.51 

199.67 

82.40 

84.39 

78.45 

232.34 

28.92 

37.27 

854.60 


Table 20. Life Cycle Cost Summary 

This table is a life cycle cost summary for Alternative 0 through Alternative 3. Each row is a major cost category and the columns represent cost for that 
relative year. Each cost category total appears in the right most column and the total cost for each alternative is the highlighted cell. 
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Alternative 0 is the baseline cost for the Joint ASW C4I Architecture. Alternative 
1 augments Alternative 0 with line-of-sight and beyond line-of-site wide band internet 
protocol based communications and Alternative 2 adds the service-oriented architecture 
capability to the Joint ASW C4I Architecture. The maintenance costs for Alternatives 0, 
1, and 2 vary only slightly. This is due to the fact that Alternative 0 is the common 
network infrastructure for the whole ship and is the major portion of the operation and 
support costs. The introduction of additional capability in Alternative 1 and 2 does not 
increase the operation and maintenance cost significantly because a ship’s automated data 
processing support staff is fixed. The operation and support cost increases for Alternative 
1 and 2 are cumulative as each alternative builds on the previous one. The highest cost 
alternative is Alternative 3. It proposes the introduction of a HALO platform to improve 
line-of-sight communication capability. This capability, if implemented, would reduce 
the latency due to beyond line-of-sight communications (eliminate satellite hops) to every 
component of a strike group. This capability requires a large investment in research and 
development in the areas of power distribution, payload, lifting gas, solar panels, energy 
storage, and production systems, drive train, and airship structure and consequently had 
the highest cost [Colozza and Dolce, 2005:8-10; Global Security: High Altitude Airship, 
2008]. Operation and support costs are assumed to be about fourteen percent per year of 
procurement costs for Alternative 3. This is in line with operation and support costs for 
Global Hawk which is another unmanned air vehicle [United States General Accounting 
Office, 2000]. The disposal costs are de-installation costs which are assumed to be small 
as compared to the overall cost of the system. The de-installation would consist of 
disconnecting power and signal cables, removing whole equipment racks, and recycling 
material and does not require careful disassembly, handling, or management of hazardous 
material. 
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VII. ANALYSIS OF ALTERNATIVES 


A. METHODOLOGY 

An Analysis of Alternatives (AoA) was conducted to compare the performance of 
the four feasible alternatives. The Analysis of Alternatives compares the alternatives’ 
ability to satisfy requirements to their life cycle cost to produce a cost-effectiveness 
comparison. This comparison allows the stakeholders to evaluate the alternatives and 
make a decision. 

To simplify the selection of the alternative, multi-attribute utility theory (MAUT) 
was used. Sage and Armstrong [2000: 414] define MAUT as, “an approach for 
evaluating, prioritizing, and ranking the outcomes associated with different action 
alternatives in complex decision situations.” The details of the MAUT process used are 
outlined in the next section. 

Choosing an alternative can often be very difficult because it is impossible to 
compare the values of multiple evaluation measures since they may be measured in 
totally different units. It is a much easier decision when the stakeholders have a single 
quantitative value. Thus, the team derived a scalar-valued function that produced a single 
quantitative value for each function and allowed the stakeholders to compare alternatives 
across all the evaluation measures. The scalar-valued function that was developed for the 
purposes of analysis is 

v[xi, ..., Xe] = WiVi[Xi] + W2V2[X2] + ... + WnVn[Xn] 

where Xi is the evaluation measure for a function, Vi(xi) is the utility score of that 
evaluation measure for the specific alternatives, and Wi is the weight of the evaluation 
measure. 

MAUT was used because it is a useful tool that takes multiple evaluation 
measures and an aggregation of individual preferences and simplifies them into a scalar¬ 
valued function that can aide in deciding between alternatives. While completing MAUT 
it was assumed that the evaluation measures used in the analysis were based on the most 
important factors of the overall system and each factor was independent of each other. 

The team understood that MAUT is based on preferences that are clearly subjective and 
sometimes the conclusions are open to question. Furthermore, while completing MAUT 
the team understood the difficulty and sensitivity in determining the weights of 
evaluation measures and their associated utility curves. Even with the shortcomings of 
MAUT, it was decided this was the best method for analysis and MAUT made it easy to 
quantify the alternatives and explain it to stakeholders. 
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B. VALUE MODELING TECHNIQUE 

The first step in MAUT is to define the evaluation measures that will be used to 
compare the performance of each of the alternatives. Five functions and their six 
associated evaluation measures were considered for comparing the performance of each 
of the alternatives. Of the five functions, four of them were the stakeholders’ top ranked 
functions. The top ranked functions are the most important functions identified by the 
stakeholders from the Value System Design survey. It should be noted these are the 
measures associated with the exact same functions considered the most important as 
discussed in the Value System and Alternatives Generation sections. The other function 
that was used, Transmit ASW Information, was also a highly ranked function and was 
easily modeled during the modeling and simulation phase. The evaluation measures that 
were considered for comparing alternatives were percentage of users with access to the 
COTP, time required to fuse data, time to interconnect, time to pull and push information, 
transmit latency, and transmit throughput. However, the percentage of users with access 
to the COTP is 100% for all alternatives as noted in the Alternatives Generation section. 
Furthermore, the time to push and pull information is the same for all alternatives as 
noted in the Alternatives Generation section. Therefore, since these evaluation measures 
were equal for all alternatives they were eliminated from the analysis. In the end, four 
evaluation measures were used to compare the alternatives: time required to fuse data, 
time to interconnect, transmit latency, and transmit throughput. 

The next step in creating the scalar-valued utility function is the development of a 
raw data matrix and utility curves in order to assign utility scores to the evaluation 
measure of each specific alternative. The raw data matrix contains the raw scores of each 
alternative with respect to each evaluation measure and is a quick way to compare 
alternatives based on their raw numbers. Utility curves were used to translate the raw 
data for each evaluation measure into a score from 0 to 1. For each alternative, this 
utility score represents what the stakeholders’ satisfaction with that attribute would be. 
The process of creating the utility curves is discussed in the next section. 

Next, weightings were developed for each evaluation measure. The weight 
computation method used was based on swing weights and was a combination of 
ordering preference and direct decision and input. The method that was followed was 
very similar to the approach used by Clemen and Reilly [2001: 615]. Swing weights are 
useful because they take into account the relative value of moving from best to worst on 
each scale. 

Finally, a decision matrix was created that assigned values for each attribute for 
the four feasible alternatives. To create the decision matrix, each alternative’s raw data 
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values were mapped onto the value curves to determine their utility scores. The weights 
were applied to the utility scores for each evaluation measure and the result for each 
alternative was summed into a single score. This single score quantified the performance 
of each alternative. 

C. UTILITY CURVES 

1. Development of Utility Curves 

Wymorian scoring functions were used to develop the utility curves because of 
the parameters that were available. Wymore [1993] developed a set of twelve standard 
scoring functions which represent twelve fundamental shapes and vary based on the 
availability of the following parameters [Daniels, Werner, and Bahill, 2001: 203]: 

• L: The parameter L is the lower threshold of performance and the value to 
the customer is undesirable (but not necessarily unacceptable) and is 
assigned a zero score. 

• U: The parameter U is the higher threshold of performance and the value 
to the customer is very desirable and is assigned a one score. 

• B: The parameter B is called the baseline value and can be chosen as the 
design goal or the status quo for this or similar systems. By definition, 
baseline values are always assigned a score of 0.5. 

• S: The parameter S determines the behavior of the scoring function in the 
neighborhood of the baseline value B. Mathematically, S is the slope of 
the tangent to the scoring function at the baseline value B. Practically 
speaking, the slope represents the maximum incremental change in the 
customer’s quantitative judgment with each incremental change in input. 

• D: The parameter D represents the domain of definition of the scoring 
function. Values outside this range constitute impossible or unacceptable 
inputs. 

For the purposes of the Joint ASW C4I Architecture, the Wymorian scoring 
functions were limited to Standard Scoring Function 3 (SSF3) and SSF9 since all the 
values for the parameters were provided by the stakeholders. SSF3 is used if “more is 
better, the customer can provide both a finite upper bound and finite lower bound’’ 
[Daniels, Werner, and Bahill, 2001: 204-205]. SSF9 is used if “more is worse, and the 
stakeholder can provide both a finite upper bound and a finite lower bound’’ [Daniels, 
Werner, and Bahill, 2001: 205]. The values for the parameters L, U, and B were 
developed by sending a survey to the stakeholders to determine their preferences. The 
stakeholders were asked to provide the following: 
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• The lowest threshold performance which the value to the customer is undesirable 
and is assigned a zero score. 

• The upper threshold performance which the value to the customer is very 
desirable and is assigned a score of 1. 

• The baseline value which is the design goal or the status quo for this or similar 
systems and is assigned a score of 0.5. 

A survey was sent to the stakeholders to develop the initial parameters and utility 
curves for the four evaluation measures. The utility curves were then sent to the 
stakeholders for feedback and approval. Ultimately, the stakeholders approved of the 
utility curves presented below. 

Example plots of SSF3 and SSF9 can be found in Figure 56 and Figure 57, 
respectively. To build the utility curves, Wymore’s Scoring Functions Tool built by Tom 
Rogers was used [Rogers, 2008]. 



Figure 56. SSF3 Utility Curve 

This is an example of a standard SSF3 utility curve [Daniels, Werner, and Bahill, 2001: 204]. 

Five parameters were needed to create the SSF3: Lower Limit (L), Baseline (B), Upper Limit (U), 
Slope (S), and Domain (D). SSF3 was used for evaluation measures that are more valuable as 
they increase. 
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SSF9(L, B, U, S, D) 



Figure 57. SSF9 Utility Curve 

This is an example of a standard SSF9 utility curve [Daniels, Werner, and Bahill, 2001; 208]. 

Five parameters were needed to create the SSF9: Lower Limit (L), Baseline (B), Upper Limit (U), 

Slope (S), and Domain (D). SSF9 was used for evaluation measures that are more valuable as 

they decreased. 

2. Fuse ASW Data Utility Curve 

The objective for the Fuse ASW Data function is to minimize data fusion 
processing time. The evaluation measure of this function is the time required to produce 
output from the Fuse ASW Data function and is measured in milliseconds. Since more is 
worse, the SSF9 curve was used. The utility curve for the Fuse ASW Data function is 
displayed in Figure 58. 
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Fuse ASW Data 



Figure 58. Fuse ASW Data Utility Curve 

This figure shows the utility curve for the function Fuse ASW Data. The x-axis is the time 
required to produce output from the Fuse ASW Data function measured in milliseconds, and the y- 
axis is the utility score. SSF9 parameters were L = 100 ms, U = 800 ms, B = 500 ms, S = - 0.003, 
and D = 700 ms. 

3. Interconnect Communication Nodes Utility Curve 

The objective for the Interconnect Communication Nodes function is to minimize 
the network join time. The evaluation measure of this function is the time for a node to 
advertise its presence, be authenticated and associated, and be capable of transmitting and 
receiving network data and is measured in seconds. Since more is worse, the SSF9 curve 
was used. The utility curve for the Interconnect Communication Nodes function is 
displayed in Figure 59. 


Interconnect Communication Nodes 



Figure 59. Interconnect Communication Nodes Utility Curve 

This figure shows the utility curve for the function Interconnect Communication Nodes. The x- 
axis is time for a node to advertise its presence, be authenticated and associated, and be capable of 
transmitting and receiving network data measured in seconds, and the y-axis is the utility score. 
SSF9 parameters were L = 1.25 s, U = 12.5 s, B = 5 s, S = - 0.3, and D = 11.25 s. 
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4. Transmit ASW Information Utility Curve 

The objective for the Transmit ASW Information function is to maximize 
transmission efficiency. As stated previously, the Transmit ASW Information has two 
evaluation measures. The first evaluation measure is latency which is the time it takes to 
pass a track through the control portion of the kill chain in the Joint ASW C4I 
Architecture. Since more is worse, the SSF9 curve was used. The utility curve for the 
latency evaluation measure for the Transmit ASW I n f ormation function is displayed in 
Figure 60. 


Transmit ASW Information (Latency) 



Figure 60. Transmit ASW Information Utility Curve (Latency) 

This figure shows the utility curve for the latency evaluation measure of the function Transmit 
ASW Information. The x-axis is the time to transmit ASW information from one internal node to 
another measured in milliseconds, and the y-axis is the utility score. SSF9 parameters were L = 
300 ms, U = 2000 ms, B = 1200 ms, S = - 0.001, and D = 950 ms. 


The second evaluation measure is throughput which was measured by modeling and 
simulation and it is the amount of data, in kilobits per second, that could flow through 
any particular platform based on the allowable bandwidth, size of the data, and time. 
Since more is better, the SSF3 curve was used. The utility curve for the throughput 
evaluation measure for the Transmit ASW Information function is displayed in Figure 61. 
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Transmit ASW Information (Throughput) 



Figure 61. Transmit ASW Information Utility Curve (Throughput) 

This figure shows the utility curve for the throughput evaluation measure of the function Transmit 
ASW Information. The x-axis is amount of kilobits that can be transmitted in one second, and the 
y-axis is the utility score. SSF3 parameters were L = 40 Kbps, U = 60 Kbps, B = 50 Kbps, S = 

0.1, and D = 20 Kbps. 

D. RAW DATA VALUES 

This section summarizes the raw data values that were obtained from modeling 
and simulation and offline analysis. As stated previously, there were four evaluation 
measures that were used to assess the performance of the alternatives. The raw data 
values for the time required to fuse data, transmit latency, and transmit throughput were 
all obtained using modeling and simulation. The raw data values for time to interconnect 
were obtained through research and analysis that was completed in the Alternatives 
Generation section. These raw data values are displayed in 

Table 21. 


Function (Evaluation Measure) 

Ideal Value 

Alternatives 

Alternative 0 

Alternative 1 

Alternative 2 

Alternative 3 

Fuse ASW Data (Time 
Required to Fuse Data) 

Less is better 

702.395 ms 

540.139 ms 

299.823 ms 

299.720 ms 

Interconnect Commimication 
Nodes (Time to Interconnect) 

Less is better 

5s 

4.5 s 

2.5 s 

2.5 s 

Transmit ASW Information 
(Transmit Latency) 

Less is better 

1334.161 ms 

1205.027 ms 

685.560 ms 

680.160 ms 

Transmit ASW Information 
(Transmit Throi^hput) 

More is bettei 

51.292 Kbps 

53.930 Kbps 

58.855 Kbps 

58.155 Kbps 


Table 21. Raw Data Matrix 
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This table shows the raw data matrix with raw scores for each evaluation measure and each 
alternative. It shows the raw scores of each alternative with respect to each evaluation measure 
and is a quick way to compare alternatives based on their raw numbers. 


E. EVALUTION MEASURE WEIGHTING 

The weight eomputation method used was based on swing weights and was a 
combination of ordering preference and direct decision and input. The method that was 
followed was very similar to the approach used by Clemen and Reilly [2001: 615]. 
Swing weights are useful because they take into account the relative value of moving 
from best to worst on each scale. Clemen and Reilly [2001: 617] explain the advantage 
to using swing weights: 


Swing weights have a built-in advantage in that they are sensitive to the range of 
values that an attribute takes on. For example, suppose you are comparing two 
personal computers, and price is an attribute. One computer costs $3500 and the 
other $3600. When you work through the swing-weight assessment procedure, 
you probably will conclude that the increase in utility from swinging the price is 
pretty small. This would result, appropriately, in a small weight for price. But if 
the difference in price is $1000 rather than $100, the increase in utility 
experienced by swinging from worst to best would be much larger, resulting in a 
larger weight for price. 


The first step in the process was to create Table 22. Each of the rows represents a 
hypothetical alternative with the first row representing a benchmark “worst case” 
scenario. Each succeeding line represents a possibility of taking just one attribute and 
swinging it from its worst value to its best. For example, the second row in Table 22 
swung the fusion time from the worst, 702.395 milliseconds, to the best, 299.72 
milliseconds. 


Attribute Swung 
from Worst to Best 

Consequence to Compare (Fusion Time, 
Interconnect Time, Latency, Throughput) 

Rank 

Rate 

Weight 

(Benchmark) 

702.395 ms, 5 s, 1334.161 ms, 51.292 Kbps 




Fusion Time 

299.72 ms, 5 s, 1334.161 ms, 51.292 Kbps 




Interconnect Time 

702.395 ms, 2.5 s, 1334.161 ms, 51.292 Kbps 



Latency 

702.395 ms, 5 s, 680.16 ms, 51.292 Kbps 




Throughput 

702.395 ms, 5 s, 1334.161 ms, 58.855 Kbps 





Table 22. Swing Weight Assessment Table 

This table shows the first step in the development of the swing weights. The benchmark row is the 
worst possible scenario of the alternatives. Each of the succeeding rows swings one of the 
attributes from worst to best. 
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With the initial table constructed, the outcomes were ranked based on interactions 
with stakeholders and their preferences. In this analysis there were five hypothetical 
architectures to compare and it was safe to assume that the benchmark architecture, the 
one that was worst on all evaluation measure, ranked fifth (worst) overall. The other four 
hypothetical architectures were compared to determine which ranked first, second, third, 
and fourth. Based on stakeholder feedback and interaction, fusion time was ranked first, 
latency ranked second, interconnect time ranked third, and throughput ranked fourth. 

The next step was to fill in the “Rate” column in the table. Two of the ratings 
were predetermined: the benchmark received a rating of 0 and the fusion time 
hypothetical architecture, the top-ranked architecture, received a rating of 100. Again, 
based on stakeholder feedback and interaction, latency received a rating of 75. This 
means that improving latency from worst to best is worth 75% of the value of improving 
data fusion time from worst to best. Along the same lines, interconnect time received a 
rating of 50 and throughput received a rating of 45 since it was just a little bit less 
important than interconnect time. 

With the rankings and rating completed, the table was completed by filling in the 
weights. Ultimately, the weights were normalized ratings and each rating is divided by 
270, the sum of all the distributed ratings. After dividing each rating by 270, fusion time 
had a weight of 0.370, latency had a weight of 0.278, interconnect time had a weight of 
0.185, and throughput had a weight of 0.167. The final rankings, ratings, and weights are 
displayed in Table 23. 


Attribute Swung 
from Worst to Best 

Consequence to Compare (Fusion Time, 
Interconnect Time, Latency, Throughput) 

Rank 

Rate 

Weight 

(Benchmark) 

702.395 ms, 5 s, 1334.161 ms, 51.292 Kbps 

5 

0 

0 

Fusion Time 

299.72 ms, 5 s, 1334.161 ms, 51.292 Kbps 

1 

100 

0.370 

Interconnect Time 

702.395 ms, 2.5 s, 1334.161 ms, 51.292 Kbp 

3 

50 

0.185 

Latency 

702.395 ms, 5 s, 680.16 ms, 51.292 Kbps 

2 

75 

0.278 

Throughput 

702.395 ms, 5 s, 1334.161 ms, 58.855 Kbps 

4 

45 

0.167 


Table 23. Swing Weight Assessment Table with Rankings, Ratings, and 
Weights 

This table shows the final table in the development of the swing weights. The rankings, ratings, 
and weights have been filled in. 

A sensitivity analysis on the effect of the weights was performed. The conclusion 
was that the relative rankings and relative magnitude was pretty insensitive to the 
weights. Furthermore, the weight distribution has no bearing on the final ranking of the 
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alternatives. Overall, the results of applying these swing weights to the utility scores 
resulted in valid relative rankings of the alternatives. 

F. DECISION MATRIX 

The next step in the process was the development of the decision matrix. The 
decision matrix was completed by mapping each alternative’s raw data values onto the 
value curves to determine their utility scores. Next, the weightings that were calculated 
in the previous section for each evaluation measure were added to the matrix. Finally, 
these weights were multiplied by the utility scores for each evaluation measure and the 
result for each alternative was summed into a single score. This single score quantified 
the performance of each alternative. The decision matrix is displayed in Table 24. 


Function (Evaluation Measure) 

Weight 

Alternatives 

Alternative 0 

Alternative 1 

Alternative 2 

Alternative 3 

Fuse ASW Data (Tinie Required 
to Fuse Data) 

0.370 

0.06 

0.36 

0.93 

0.93 

Interconnect Communication 
Nodes (Time to Interconnect) 

0.185 

0.5 

0.65 

0.96 

0.96 

Transmit ASW Information 
(Transmit Latency) 

0.278 

0.37 

0.49 

0.9 

0.9 

Transmit ASW Information 
(Transmit Throughput) 

0.167 

0.63 

0.83 

0.99 

0.98 

Total Score (0-1) 


0.32 

0.53 

0.94 

0.94 

LCCE($Mil) 


92.70 

118.69 

133.37 

829.00 


Table 24. Decision Matrix 

This table shows the decision matrix and the estimated performance of each alternative as 
weighted utility scores for each evaluation measure. 


G. UTILITY SCORE VERSUS LIFE CYCLE COST 

The final step in the analysis of alternatives was to compare the utility score to the 
life cycle cost. This was done using a utility versus life cycle cost plot which is shown in 
Figure 62. This plot allows for decision makers to visually compare the alternatives in 
regards to performance versus cost. The utility score versus life cycle cost plot was sent 
to the stakeholders for a final decision. 
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LCCE($MIL) 


Figure 62. Utility vs. LCCE Plot (All Alternatives) 

This figure shows the utility of each alternative while displaying the estimated cost to achieve that 
performance. 

Based on the utility versus cost it was very clear that Alternative 3 should be 
discarded since it has the same utility as Alternative 2 but costs more than six times as 
much. That left three remaining alternatives which were plotted again using a utility 
versus life cycle cost plot to increase the ability to make a distinction between 
alternatives. This plot is shown in Figure 63. 


178 
















LCCE($MIL) 


Figure 63. Utility vs. LCCE Plot (Alt 0,1, and 2) 

This figure shows the utility of each alternative after the elimination of Alternative 3. 


Among the three remaining alternatives, Alternative 2 had the highest LCCE at 
$136.92M, Alternative 1 has the second highest cost at $121.1 IM, and Alternative 0 
$95.09M. Subsequently, the alternatives were also ranked in the same order for 
performance. Therefore, the decision was based on whether the stakeholders want to 
spend more money for more performance. 
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VIII. FINAL RECOMMENDATIONS AND CONCLUSIONS 


A. CONCLUSION 

This report is the result of this capstone project design team’s effort to provide the 
ASW community well-researched alternatives for obtaining and maintaining a robust 
Joint ASW C4I Architecture enabling reduction of communication exchange time from 
sensor awareness to weapons on target in FY2020 and beyond. A tailored systems 
engineering process consisting of five phases: needs analysis, value system design, 
alternatives generation, model alternative, and alternative scoring was employed in the 
development of the Joint ASW C4I Architecture. 

The first step in the process was needs analysis. In this step, the primitive 
stakeholder need was transformed into an effective need through a set of processes, 
stakeholder analysis, threat analysis, functional analysis, and futures analysis. The 
resulting effective need statement was assessed by the stakeholders and the capstone 
project team. 

A stakeholder analysis was completed to identify relevant stakeholders, their 
needs, and what was most important to them. The stakeholder analysis concluded that 
reducing the time in the kill chain and the accuracy and integration of underwater, 
surface, air, and space sensor systems along with fusion of contact data from these 
systems were most important. 

A threat analysis helped to scope and bound the problem. It highlighted the fact 
that the threat from enemy submarines includes elements beyond the submarine itself 
such as its command and control, country’s ideology, supply system, and fleet support 
units. Further, the threat was addressed across the life span of its operational use 
including its initial design stage, parts production and fabrication, and the launch of an 
operationally ready submarine. The analysis led this capstone project design team to 
focus on two specific phases of the enemy submarine’s life cycle: before its subsystems 
are completely integrated (pre-full operational capability) and after it has become a fully 
operational unit capable of conducting sea-going missions (full operational capability). 

A functional analysis was completed to help translate stakeholder requirements 
into detailed design criteria and to help identify the resources necessary for system 
operation and support. Research was conducted and the Net-Centric Operational 
Environment Joint Integrating Concept, the Net-Centric Environment Joint Functional 
Concept, and the Tactical Wireless Joint Network Concept of Operations were identified 
as important net-centric documentation. Analyzing the aforementioned documents 
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allowed the system boundary to be identified, which established the interfaces between 
the Joint ASW C4I Architecture and other systems. Establishing the system boundary 
helped to determine what functions the system should accomplish and provided the 
justification for the components that are implemented in the system. Overall, the 
functional analysis provided the basis for developing innovative alternatives independent 
of any specific technical solution. A functional hierarchy was developed that 
decomposed the system into five top-level functions: provide connectivity; perform 
information operations; optimize network functions and resources; transport ASW 
information from end-to-end; and provide ASW data and information management. 
IDEFO diagrams were developed to identify and analyze the functions that are performed 
by the system. The IDEFO products were a coordinated set of diagrams that helped 
facilitate understanding using both graphical and natural language. Additionally, the 
diagrams served as a reference architecture for analysis during alternatives generation. 

A futures analysis was completed to make educated predictions with respect to the 
future operational environment; in this case the future environment that was addressed 
extends to the year 2020. The most important piece of information learned from this 
analysis is that the Joint ASW C41 Architecture must align, support, and adapt to the 
service-oriented architecture to enable a true net-centric operational environment as 
envisioned in the Net-Centric Operational Environment Joint Integrating Concept. 

Needs analysis concluded with the development of the following effective needs 
statement: Key ASW stakeholders require a new standardized joint ASW-specific C41 
architecture for the 2020 target time frame. The proposed Joint ASW C41 Architecture 
needs to use open standards, common waveforms, and a common data schema, ft needs 
to be consistent with DoD policy and processes and be vertically integrated with other 
DoD C41 systems, ft will enhance the commander’s ability to execute the joint ASW 
mission in support of a Combatant Commander’s campaign objectives [NCOE JIC, 

2005]. The purpose of the architecture is to guide development and to support 
engineering, force composition, and acquisition decisions. 

The next step in the process was the value system design. The functions were 
decomposed into sub-functions down to the lowest logical level. Evaluation measures 
were then identified based on stakeholder feedback to determine satisfactory performance 
of those objectives. The iterative value system design process yielded twenty functional 
evaluation measures, and four non-functional evaluation measures for a total of twenty- 
four evaluation measures. The large number of functional evaluation measures is 
indicative of the complexity of the Joint ASW C4I Architecture. The evaluation 
measures were then ranked, by the stakeholder, to determine the most important functions 
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of the system. The top-ranked functions from most important to least important were: 
Provide ASW COTP, Fuse ASW Data, Interconnect Communication Nodes, Enable 
Smart Pull and Push of Information, and Transmit ASW Information. 

The third step in the process was the alternatives generation. The alternatives 
generation process consisted of five separate actions: research, construction of a FY2020 
Joint ASW C4I Architecture Baseline, functional gap analysis, stakeholder value 
hierarchy survey, and brainstorming of alternative solutions which were completed in 
series. From this process, four feasible alternative solutions were developed. The four 
feasible alternative solutions consisted of Alternative 0 (Baseline Architecture) which 
includes Joint Surveillance and Target Attack Radar System (JSTARS), satellite 
communication links. Surveillance and Control Data Link (SCDL), Joint Tactical 
Information Distribution System (JTIDS), Tactical Air Navigation (TACAN) operation. 
Tactical Data Information Link-J (TADIL-J), the Tactical Common Data Link (TCDL), 
and the Tactical Control System (TCS); Alternative 1 (Baseline Architecture plus JTRS 
Increment 4, NECC, and CANES improvements); Alternative 2 (Baseline Architecture 
plus JTRS Increment 5, CANES improvements, and Joint Track Manager); and 
Alternative 3 (Baseline Architecture plus modulated x-ray source communications 
system, autonomous C4ISR UUVs, military HAA, use of HALO, Helios, and HAA for 
tropospheric or space-based distribution and fusion of COTP, and wireless users capable 
of pulling and pushing information directly to a satellite or HAA based network by way 
of HALO, Helios, and HAA). The resulting alternative solutions conformed to 
stakeholders needs, were functionally correct and feasible. 

The fourth step was the modeling and simulation of the four feasible alternatives. 
In this step, EXTEND was chosen as the primary modeling tool. Performance models for 
each alternative were built based on the developed scenario, IDEFO, and functional flow 
block diagram. Simulation was performed to generate data related to evaluation 
measures developed in the value system. The evaluation measures identified using these 
tools were throughput, latency, and data fusion time. Alternative 2 had the greatest 
throughput. Alternative 3 had the lowest latency value and lowest data fusion processing 
time. The results from the modeling and simulation were used in the alternative scoring 
step. Furthermore, the model alternative step included life cycle cost estimation. The life 
cycle cost estimate included research and development, production and installation, 
operation and support, and disposal costs. It involved the costs of all technical and 
management activities throughout its lifetime and provided the basis for comparing 
alternatives. A cost model was developed to calculate the cost of each task, life cycle 
phase, and year. From this cost model, it was determined that the least expensive 
alternative was Alternative 0 at a life cycle cost of $95.09M over a nine year projected 


183 



lifespan. In order of increasing costs, the other alternatives were Alternative 1 at 
$121.1 IM; Alternative 2 at $136.92M, and Alternative 3 at $854.60M. 

The final step, alternative scoring, was conducted to compare the performance of 
the four feasible alternatives. The alternative scoring step compared the alternatives’ 
ability to satisfy requirements to their life cycle cost to produce a cost-effectiveness 
comparison. This comparison allowed the stakeholders to evaluate the alternatives. To 
simplify the selection of the alternative, classic multi-attribute utility theory was used 
with adequate stakeholder feedback. Based on the utility versus cost developed using 
multi-attribute utility theory, it was very clear that Alternative 3 could be discarded since 
it has a lower utility than Alternative 2 and costs more than seven times as much. The 
remaining three alternatives were analyzed and it was determined that Alternative 2 is 
recommended for further development. Alternative 2 provides significant improvements 
in utility for a small cost. Further investigation and validation of Alternative 2 is 
recommended in a real world event. 

Overall, this capstone project design team learned that functional C4I 
characteristics are not unique to the ASW community and demand appropriate levels of 
funding to address operational user C4I needs. Our research indicated that planned 
United States Navy programs of record are being positioned to solve most ASW 
stakeholder concerns with a joint C4I network architecture near or soon after the 
established baseline of FY2020. Future C4I capabilities impacting ASW forces are very 
much dependent upon DoD joint service and United States Navy fleet wide resourcing 
activities to cross-leveling of future DoD funds across all services and agencies 
contributing to the ASW mission. Equal resourcing of all naval warfare areas and 
warfighting platforms is paramount in ensuring the ASW community receives its fair 
share of research and development, operations and support, and procurement funding to 
develop and acquire mature C4I networking technologies for ASW operational forces. 
The ASW community must proactively seek out all available resources. ASW 
operational C4I standards must be solidified by FY2020. The ASW community must 
maintain a focused approach to best resource and acquire the necessary tools to achieve 
improvements in C4I attributes submarine sensing devices, data transmit-receive 
techniques, and enemy submarine engagement tools requiring data transmission 
capabilities. 

Finally, we learned that the Navy has individual systems that solve a piece of the 
C4I architecture with no broader program office that manages from the system of systems 
level. To properly manage the C4I architecture, a system of systems architect is required. 
This would likely be from PEO-C4I, PEO-IWS, or new full-time funded acquisition 
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organization. This architect would have a staff to perform the system of systems 
modeling and simulations in much greater detail and depth than this projeet team did and 
inelude elassified data sets. The arehiteet would address the various follow-on projeets 
indentified that need to be addressed at a system of systems level and, most importantly, 
enable cross-program manager collaboration. 

B. AREAS FOR FURTHER CONSIDERATION 

The following areas of interest are offered to United States Navy ASW 
operational users and aequisition community to develop and staff requirements 
documents - initial eapability, capability development, or eapability production from 
which new teehnology can be obtained for operational use beyond the FY2020 
timeframe: 

1. Identify inerement developments of C4I integration tools to improve 
interoperability of United States ASW forces with eoalition forees. 

2. Collaborate with all United States government ageneies and departments to 
ensure eoordination and integration of all C4I plans and aequisitions to optimize 
interoperability with United States Coast Guard and others concerned with 
maritime domain awareness issues. 

3. Development or redesign of sensors and weapons should be eonsidered with 
the eoneept of data fusion and data sharing beeause of the potential iterative 
improvements of aeeuraey that can be obtained. 

4. Continue to monitor, support and fund, as necessary, taking the ASW 
community towards next generation sub-surfaee and surface systems 
interoperability initiatives using autonomous or semi-autonomous UUV, UAV, 
and HAA or vehieles utilizing advaneed artifieial intelligenee, 
nanotechnology, and neural nets with laser and wireless networks. 

5. Follow-on projeets are needed to address lower tiered elements that were 
outside the seope of this projeet, but are neeessary. This ineludes training, 
knowledge management, human systems integration, role based aceess to services 
and data, archiving for intermittent or disadvantaged users, redundancy for 
network eonneetivity, and available spaee on platforms for the processing 
hardware. Another excellent follow-on study would be to assess the users and 
concepts of operation used with a new C4I architeeture sinee it may change the 
way ASW can be eonducted. 

6. Investigate utility of proposed Joint ASW C4I Arehiteeture modeled against a 
possible scenario combating a submarine launehed anti-submarine cruise missile. 
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7. Conduct a more detailed study of the threat to the Joint ASW C4I Arehiteeture. 

8. Conduet additional researeh and obtain details about possible laser 
communieations and impaets on communication, speed, and depth assertions. 

9. It was our understanding that the ASW COI was eondueting an ASW data 
schema analysis. However, there may be a need to conduct additional research 
and extract detailed approaches for data sehema roles and responsibilities of the 
ASW community to ensure its compliance with DoD certified serviee-oriented 
arehitectures and any promising eommercial data sehema solution. Future work 
must inelude in-depth study of the complete data schema strueture; the system of 
information transport, serviee-oriented architecture, and data definition. 

10. Utilize operationally ready systems engineering models and tools to optimize 
value system design and permit use of real world elassified data sets as required 
for better deeision making on the part of the ASW community. Models and tools 
to consider inelude: 

a. Network Warfare Simulation (NETWARS) - re-designated as Joint 
Communications Simulation System (JCSS) in 2007. It represents the 
Joint Chiefs of Staff standard for modeling military communication 
systems. It represents an integrated ability to analyze communieation 
networks while also providing a validated simulation eapability with 
databases and underlying models so that studies ean be consistent 
throughout the unified eombatant eommands, serviees, and others within 
the eommand, eontrol, communieations, and computer systems 
community. 

b. Optimized Network Engineering Tool (OPNET) - provides a 
comprehensive development environment for the specification, simulation, 
and performance analysis of eommunication networks. 

c. QualNet Developer - is ultra high-fidelity network evaluation software 
that predicts wireless, wired and mixed-platform network and networking 
device performance. It supports hardware, software, and human-in-the 
loop testing over thousands of network nodes. 

d. Multi-Generator (MGEN) - open source software developed by Naval 
Research Laboratory (NRL) PROTocol Engineering Advaneed 
Networking (PROTEAN) Research Group. MGEN provides the ability to 
perform IP network performanee tests and measurements. 
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11. Conduct research to develop operational mission sets for combined ASW 
unmanned vehieles and netted sensor deviees. 

12. Conduct sensitivity analyses on impaets to Joint ASW C4I Architeeture by 
reduetion of man-in-loop human interface time and what it might mean to 
inereasing target identifieation. 

The United States Navy and, more speeifieally, the ASW eommunity stakeholders 
are turning the comer to regain undersea warfare prowess. Use of a robust Joint ASW 
C4I Architeeture by all ASW platforms and supporting operational joint units prior to and 
beyond fiseal year 2020 will enable eontinued network enhaneed ASW mission 
performance. 
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APPENDIX A. PROJECT PLAN 


INTRODUCTION 
PROJECT DESCRIPTION 

We, the members of the 311-071 cohort capstone project team, will create an Anti- 
Submarine Warfare (ASW) specific joint Command, Control, Communications, 
Computers, & Intelligence (C4I) architecture that fulfills the goal of enhancing the 
combatant commander’s ability to execute a mission in support of his or her campaign 
objectives. C4I has to support cueing, turnover to tactical platforms, and prosecution up 
to weapons on target. The architecture will consider the offensive and defensive actions 
contained in the National Military Command Authority Global ASW Concept of 
Operations. The following subsections provide the detailed description of the problem 
and what our end state will look like. 

Problem Statement 

Existing platforms whose primary or collateral missions include ASW were 
designed in large part with functionally stove-piped communication architectures. These 
architectures often have limited or no interoperable capabilities with existing 
communication systems. They lack robust routing and networking capabilities, are 
capable of only low to medium data throughput, and present logistics challenges due to 
their stove-piped nature. Key ASW stakeholders require a new joint C4I architecture that 
uses open standards, common waveforms, and common data schema for the various data 
classes supported by development of the requisite Department of Defense Architecture 
Framework (DoDAF) products to implement and enable joint network-centric ASW 
operations. 

Vision 

Our vision is to create a C4I architecture that allows for the employment of joint 
networking capabilities at the tactical and operational level to fulfill the goals of the Net- 
Centric Operational Environment (NCOE) Joint Integrating Concept (JIC) of enhancing 
the commander’s ability to execute the joint ASW mission in support of a combatant 
commander’s campaign objectives [NCOE JIC, 2005]. 

End State 

An ASW-specific open systems architecture will be developed that is aligned with 
the NCOE JIC and more specifically aligned with the Information Joint Enabling 
Construct appendix of the NCOE JIC. Some of the features of this architecture will be 
the ability to install and deploy a scalable, modular network that is survivable and 
maintainable while providing the ability to transport information from end-to-end with 
strong information assurance. This architecture will provide a roadmap to implement the 
enhancements inherent in network centric operations. Some of these enhancements 
include real-time access to available data on the Global Information Grid; backward 
compatibility with legacy tactical data links and voice; a common operational picture; 
and seamless interoperability. Additional enhancements include increased bandwidth; 
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simultaneous voice, data and video operations; a reduced logistics footprint through an 
enterprise set of hardware and software solutions; and the ability to rapidly check in and 
check out of the network without loss of data or loss of precedence. 

A future end state would include the ability to communicate with submarines at 
speed and depth. This would include sharing data via acoustic data links from various 
underwater sources to onboard computers. Then, the data would be shared from the 
computers to digital data links via antennas to the fleet and back again to the underwater 
sources. 

SUPPORTING ACTIVITIES AND BACKGROUND 

The ASW Community has recently been registered as an Office of Secretary of 
Defense Community of Interest (COI) for data sharing. Under the Integrated Warfare 
Systems-5 (IWS-5) leadership, the ASW COI has initiated a data management 
workgroup. This group has begun development of data standards. In addition, the group 
has begun development of a pilot project that is focused on air and shore classes of data 
and information sharing architecture. Therefore, it is a relevant subset to this capstone 
project. The pilot project is facilitated and led by NFS Professor Brutzman. 

IWS -5 is one of the primary supporting activities for ASW. It is the Navy office 
responsible for all ASW software and interoperability development as well as the process 
developer for planning capability evolution. In particular, it is also responsible for 
changes to the Littoral Combat Ship Mission Module ASW Package. They have recently 
developed an ASW Mission Capability Architecture to establish a baseline for 
improvements in interoperability, performance, and evolution. It is based on traditional 
command relationships, system level controls, and data or information distribution. 
Additionally, it does not include joint extensions for the expanded composable ASW 
force. 

Open architecture, net-centric operations, and distributed netted sensors should 
enhance operational interoperability among non-traditional entities, such as the United 
States Coast Guard (USCG). Traditionally, the USCG had an ASW role that was 
minimized in the post cold war period. So, the ability of new platforms, such as the 
USCG’s new Naval Security Cutter, to participate in ASW as a member of the 1000 ship 
Navy has not been adequately explored. Program Executive Office (PEO)-Integrated 
Warfare Systems agrees that the Navy lacks a revised set of operational views and 
systems views for a next-generation composable ASW force based on net-centric 
operations and presumed data sharing. 

THREAT AND WARFIGHTING DISCUSSION 

Admiral J. L. Johnson, former Chief of Naval Operations was quoted, "Anti- 
Submarine Warfare is a core enduring naval competency that will be a vital mission in 
the 21st Century" [Anti-Submarine Warfare, 2008]. This statement surely suggests that 
enemy submarines of every size and capability pose a very real threat to the United States 
and its coalition forces. Specifically, the threats today are quiet diesel submarines 
operating in littoral environments as well as submarines operating in open ocean 
environments. Further, there is a very real threat of communications disruption from the 
adversary destroying communications satellites. These environments pose 
communications and connectivity challenges. 
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Here is a quote from “Anti-Submarine Warfare: A Phoenix for the Future” 
which describes a fundamental truth about ASW: 

ASW is a team sport - requiring a complex mosaic of diverse capabilities in a 
highly variable physical environment. No single ASW platform, system, or 
weapon will work all the time. A wide spectrum of undersea, surface, airborne, 
and space-based systems to ensure that we maintain what the Joint Chiefs of Staff 
publication Joint Vision 2010 calls full-dimensional protection. The undersea 
environment, ranging from the shallows of the littoral to the vast deeps of the 
great ocean basins - and polar regions under ice - demand a multi-disciplinary 
approach, subsuming intelligence, oceanography, surveillance and cueing, 
multiple sensors and sensor technologies, coordinated multi-platform operations, 
and underwater weapons [Anti-Submarine Warfare, 2008]. 

ORGANIZATION STRUCTURE 

Our team consists of 11 team members located in five different geographical 
locations. We divided the roles and responsibilities into two categories: systems 
engineering product development responsibilities and project management 
responsibilities as displayed in Figure 64. We reserve the right to reassign personnel 
between the product development and project management areas within the organization 
to balance the workload as the project progresses. 
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Figure 64. Organization Chart 


Systems Engineering Product Development Responsibilities 

The systems engineering product development responsibilities show which 
product area each individual team member is responsible for during the project. The 
product development responsibilities are divided into five general systems engineering 
categories: needs analysis, value system design, alternatives generation, model 
alternatives, and alternative scoring. These responsibilities are detailed in section 2: 
Systems Engineering Approach. 

Project Management Responsibilities 

The project management responsibilities show which overarching area each 
individual team member is responsible for during the project. They are divided into six 
categories: leader, scheduler, librarian, modelers, editors, and meeting minutes. 
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Leader 

The team leader’s primary responsibility will be to facilitate the overall 
coordination of the project. This includes being the chair of total team meetings, 
preparing the agenda, reviewing the schedule, getting collaboration on issues, reaching 
decisions, assigning action items with due dates, and managing the project risks. In 
absence of the leader, the deputy leader will fill these responsibilities. The leader and 
deputy leader will be the final sign off of the project plan. Their signature represents the 
concurrence of the whole class. 

Scheduler 

The scheduler will be responsible for developing project schedules and tracking 
group progress versus planned due dates. The scheduler will also be responsible for 
posting the current schedule on Blackboard upon team leader approval. Finally, the 
scheduler will provide status of group performance in meeting timelines during scheduled 
integrated product reviews. 

Librarian (Configuration Manager) 

The librarian will also be the configuration manager and responsible for keeping a 
complete audit trail of decisions, design modifications, and documented changes. This 
includes gathering and cataloguing all reference material provided by the team. The 
configuration manager will also be responsible for version control of all project 
documentation including the final report and briefing packages. Version control will be 
accomplished using a numerical revision number in combination with the date. The 
revision number ensures that editorial consistency is maintained. The Blackboard group 
file exchange will be utilized to exchange and store versioned files. The configuration 
manager will be responsible for archiving and keeping a backup copy of all files posted 
to the Blackboard group file exchange. 

The use of configuration management tools will enable us to apply industry 
standards to all documentation. It will also enable us to manage the quality and 
development of products as the system is developed for the final proposal. The process 
and procedures utilized in providing guidance are the American National Standards 
Institute/Electronic Industries AIIiance-649 [1998], Military Handbook-61A (SE) [2007], 
and the Defense Acquisition Guidebook [2006] Chapter 4, section 4.2.3.6. 

Documentation of any systems engineering project must be maintained 
throughout the development and operational life of a system. This ensures the integrity 
of the information and process, providing the stakeholder or customer a reliable product 
and documentation trail for audit, revision, and requirements. 

Modelers 

The modelers will be responsible for the development of a life cycle cost (LCC) 
model, a functional performance model, and an operational performance model. Within 
the modelers, there will be two focus groups: one will concentrate on the LCC models 
and the other will concentrate on both functional and operational performance models. 
The LCC will assess the affordability of the various alternatives. The functional 
performance model will be used to verify what the system and sub-system must do, as 
well as determining the outputs through the use of simulation. The 
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operational performance model will be used to assess the impact to interoperability and 
overall mission effectiveness through the use of simulation. 

Editors 

The editors will be responsible for the editorial aspects of the report, which 
include reviewing, rewriting, and editing the work of teammates. They will be 
responsible for formatting, spelling, grammar, resolving conflicts, and making the report 
a cohesive document. During the editorial process, it is important that the editors 
communicate directly with the author and the rest of the team. The editors will collect, 
merge, and render a final editorial decision on each submission. Editors will also be 
responsible for verifying the correct format of all the citations and references in the 
report. American Psychological Association format will be used for citations and 
references. However, it is the task of the author to provide the citations and the 
references. It is the editor’s responsibility that all citations and references are 
incorporated adequately and consistently throughout the report. 

Meeting Minutes 

Since our project team consists of 12 people from six different locations, effective 
meetings are required. An important element of those meetings is documenting the 
decisions reached and the actions taken. Thus, it is important to have a dedicated 
individual taking meeting minutes and then sending them to the whole team upon 
completion of the meeting to keep everyone in the group informed of project progress. 
Furthermore, this person is responsible for keeping track of the status of all action items 
to ensure success of the project. 

STAKEHOLDERS 

The following organizations stand to gain from the success of the C4I architecture 
being developed. They can be grouped into resources sponsors, the acquisition 
community, and the user community. 

Disagreement among stakeholders will be handled in the following ma nn er. If the 
disagreement is within the organization with one being the higher authority, then we will 
use the higher authority direction, but inform the lower authority of this decision. If the 
disagreement is between peer groups, then we will attempt to adjudicate. If resolution 
cannot be reached, the project team will decide. There is a desire to develop a useful 
product, but there is an overriding requirement to complete the product on time. 

Resource Sponsors 

This group sponsors the requirements. Their interest is leveraging their resources 
across projects. C4I provides a tremendous financial leveraging opportunity. 

• N-6 - Communication Networks 

• N-86 - Ship resource sponsors. 

• N-87 - Submarine resource sponsors. 

• N-88 - Air Warfare 
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Acquisition Community 

This group designs, interfaces with and procures C4I equipment under the 
sponsorship of the resource organizations above. 

• Program Executive Office, Littoral and Mine Warfare 

• Program Manager Ships-485, Maritime Surveillance Systems 

• Program Manager Ships-420, Littoral Combat Ship, Mission Modules 

• Program Executive Office, Integrated Warfare Systems-5 

• Program Executive Office, C4I 

User Community 

This community drives the requirements for C4I architectures. They can greatly 
leverage their tactical and operational superiority through a joint open C4I architecture. 

• Commander Undersea Surveillance 

• Commander Naval Meteorology and Oceanography Command 

• Navy and Mine and ASW Warfare Center 

• ASW Cross Functional Team - This community plays an important role in ASW 
C4I requirements. 

• Pacific Command 

• Department of Homeland Security: Maritime Domain Awareness 

• United States Coast Guard: Deep Water Program Manager 

• United States Coast Guard C4I 

RISK MANAGEMENT 

The risk to the project will be regularly reviewed by the project leader and deputy 
leader through solicitation from the team members. The risk analysis will be 
documented in an if-then format as shown in the examples below. A risk management 
sheet for each risk will be developed that will capture the risk description, risk 
management decision, impact and likelihood of occurrence rating, plans, and status of 
those plans. Once identified, the leader and deputy leader will assess whether to watch, 
mitigate, or transfer the risk. If watched or mitigated, contingency plans will be 
developed. If mitigated, the risk will be assigned to a teammate. Then, steps to mitigate 
will be developed, approved by the team, and executed. Status of the mitigation or 
contingency plan will be an agenda item at team meetings. The initial risks identified for 
this project are: 

• If the problem scope is too large, then the project may not be completed in the 
period of performance (PoP). 

• If the model development is too complex, then the project may not be completed 
in the PoP. 

• If members of our team are not proactive and do not take ownership of their 
tasking or ask questions when they do not understand, then the project may not be 
completed in the PoP. 
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• If the stakeholders do not participate and provide feedback in the interim project 

reviews, then the value and accuracy of the project could be reduced. 

SYSTEMS ENGINEERING APPROACH 
OVERVIEW 

We examined a number of systems engineering processes in evaluating an 
approach to the project. The “Vee” approach, Hatley Pirbhai, the “Spiral” approach, and 
the Systems Engineering Design Process (SEDP) as taught at NPS were all evaluated on 
suitability and applicability to the task [Blanchard and Fabrycky, 2006: 30, 34]. We need 
to ensure that there is a proper requirements analysis that is clearly defined and is 
traceable to what the stakeholders require. Through a multi-step process, we are seeking 
to apply rigorous systems engineering tasks to those refined requirements to develop a set 
of feasible alternatives, evaluate those alternatives against each other, and then select a 
preferred alternative to be presented to the stakeholders for final approval. The multi- 
step process has to be flexible and iterative in nature to allow for feedback throughout the 
process with the intent to positively influence the outcome. This will provide the best 
possible alternative within cost, performance, schedule, and other constraints (e.g., 
political or environmental). 

All the examined systems engineering processes were found to be suitable 
for the task. However, a tailored SEDP was selected as the preferred process due to the 
variety of tools available to complete each step of the overall process and our overall 
familiarity with that particular process. Figure 65 shows our tailored SEDP. There are 
five tier two processes: needs analysis, value system design, alternatives generation, 
model alternatives, and alternative scoring. Each tier two process has a summary input 
and output deliverable. These deliverables are a roll up of lower tier tasks that are 
highlighted in the toolkit text boxes. It should be noted that the toolkit boxes are not all 
inclusive of every potential option available to help complete its associated tier two 
process but is representative of what we have at our disposal. We have not yet evaluated 
which tools we will use to complete each tier two process. Figure 65 also shows the 
iterative nature of the overall process. Each output is intended to be reviewed first by us 
and second by the stakeholders. Once approval of the output deliverable is achieved, it 
becomes the input for the next tier two process. If neither the stakeholders nor us are 
satisfied with a tier two output, the systems engineering effort backs up to an appropriate 
tier two process and starts again. Some output deliverables will be compared to the input 
deliverable to check for consistency and traceability. Our team will utilize tools such as 
CORE for requirements traceability. The final step is a decision by the stakeholders on 
the recommended alternative. Should the stakeholders not approve of the recommended 
alternative, then the process can move back to any subsequent point to re-engage and 
work to another recommended alternative. 
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Figure 65. Tailored Systems Engineering Development Process 
NEEDS ANALYSIS 

The first tier two proeess we will perform is that of a needs analysis. We will take 
the primitive stakeholder need as an input and through the use of numerous tools will turn 
it into an effective need as an output. While we have not yet settled on which tools we 
will use, it is likely that a stakeholder analysis, a threat analysis, a functional analysis, 
and a futures analysis will be performed. Another tool available to us to assist in 
developing the effective need statement is the development of use cases. The effective 
need statement will be assessed by the stakeholders and us. 

VALUE SYSTEM DESIGN 

Upon stakeholder approval of the effective need, that deliverable will serve as 
input to the next step, which is a value system design. The value system design will 
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begin with identification of the major functions the system must perform. The functions 
will be decomposed into sub-functions down to the lowest logical level. The lowest level 
sub-functions will have objectives assigned. Evaluation measures must then be identified 
to determine satisfactory performance of those objectives. The output of the value 
system design will be the problem definition statement. 

ALTERNATIVES GENERATION 

Upon approval of the value hierarchy, it will be used as input into the alternatives 
generation process. This process may utilize a Zwicky’s morphological box, trade 
studies, or a combination of these methods. All phases of the threat life cycle (e.g., 
industrial capability, under construction, in port, training, or at sea) will be considered 
when brainstorming alternative C4I architectures intended to enhance mission 
effectiveness. As alternatives are identified, the evaluation measures developed in the 
value system design will be utilized to differentiate between feasible and infeasible 
alternatives. Each alternative will be assessed and a list of feasible alternatives will be 
the output of the alternatives generation step. 

MODEL ALTERNATIVES 

Using the approved feasible alternatives as an input, the model alternatives step 
will begin. We expect to perform functional modeling of the feasible alternatives. This 
functional modeling may be scenario-based, processing-based, control-based, data-based 
or a combination. It is expected that at a minimum, processing and control-based 
functional modeling will be performed yielding the appropriate outputs (e.g., IDEFO & 
functional flow block diagram). We also expect to build performance models. The 
modeling tools are yet to be determined. Finally, we expect to perform life cycle cost 
modeling of each of the feasible alternatives. It is unlikely that an engineering life cycle 
cost model will be utilized due to time constraints, but analogy and parametric life cycle 
cost models are likely candidates. Simulation, where applicable, will be performed to 
generate data related to evaluation measures developed in the value system design and 
the output of this step will be the modeling and simulation (M&S) results. 

ALTERNATIVE SCORING 

Using the results from the M&S step as an input, the alternative scoring step will 
begin. The relevant M&S results will be inserted in a raw data matrix. From there, we 
will apply an objective decision making tool such as multi-attribute utility theory to turn 
raw scores into utility scores. Those scores may be further weighted, value curves may 
be developed, and the final set of data will go into a decision matrix. The output of this 
step will be the prioritized alternatives list. 

BEST ALTERNATIVE 

Upon approval of the prioritized alternatives list by us, we will agree upon the 
recommended alternative. This recommended alternative, along with the entire 
prioritized list will be forwarded to the stakeholders for consideration. Should the 
stakeholders approve our recommendation, we would wait for further tasking from the 
stakeholders for implementation. Due to curriculum schedule constraints, we do not 
believe we will get beyond the decision step. Should the stakeholders reject the 
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recommended alternative in favor of one of the other alternatives, the next step would 
also be implementation of that alternative. Should the stakeholders reject all the 
prioritized alternatives, then an assessment of where the systems engineering process 
needs to be reengaged would be performed and the process would be restarted. 

MILESTONES AND DELIVERABLES 


Milestone 

Description 

Deliverable 

Date 

1 

Project Management 
Plan Approval 

Project Management Plan 

(Primitive Need) 

4 February 
2008 

2 

Integrated Product 
Review - #1 

Problem Definition 
Report (Effective Need; 
Problem Definition 
Statement) 

1 April 2008 

3 

Integrated Product 
Review - #2 

Modeling and Simulation 

16 June 2008 

4 

Final Report 
Submission 

Best Alternative 

8 August 2008 

5 

Integrated Product 
Review - #3 

Project Presentation and 
Final Report 

25 August 2008 


Table 25. List of Milestones and Deliverables 
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Figure 66. ASW C4I Project Management Plan and Milestones 


Critical Path Method 

The critical path method is a “technique that aids understanding of the 
dependency of events in a project and the time required to complete them. Activities 
which, when delayed, have an impact on the total project schedule are critical and said to 
be on the critical path” [Defense Acquisition Guidebook, 2001]. The Gantt chart, Figure 
66, represent the critical tasks and subtasks of this project. They are scheduled to occur 
in the following order: project management plan, needs analysis, value system design, 
alternatives generation, model alternatives, alternative scoring, and best alternative. 
However, task and process overlapping is planned to ensure schedule efficiencies. 

Timely, efficient management and completion of each individual task and subtask 
is paramount to our overall project success. We have identified the most critical task of 
our project to be model alternatives due to its perceived complexity and it being the 
longest individual task requiring careful management of time and resources. Four 
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additional subtasks further refine our project’s critical path: functional analysis; Value 
Hierarchy; Alternative Generation Process; and Performance Modeling and Simulation. 
All four subtasks are significant to qualifying and quantifying our findings. 

Our cohort has begun researching areas for our needs analysis while final staffing 
and approval actions are being taken on the project management plan. Detailed analyses 
will provide our value system design team the data needed to establish the necessary 
input metrics for the alternatives generation process. In order to model alternatives it will 
be imperative to permit our modelers the maximum amount of time to identify, choose, 
and gain the requisite experience to afford well-organized modeling activities. They also 
need time to evaluate models for use in this project to offer the highest quality output data 
sets. Modeling and simulation results will set the stage for the derivation of Feasible 
Alternative data and presenting opportunities supportive to alternative scoring. 

Ultimately, these results will allow us to prioritize the alternatives to identify the best 
alternative in the final report recommendation to our stakeholders. 
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APPENDIX B. NET-CENTRIC SYSTEM REQUIREMENTS 


Based on our research and feedback from the stakeholders, five main capabilities 
that are required for a net-centric system were defined. From these five capabilities, 
seventy-eight top level requirements were identified to be necessary in building a net- 
centric architecture. All of the capabilities and requirements for a net-centric system are 
listed below: 


Ability to Provide Connectivity 

• Establish a collaborative session [NCOE JIC, 2005 :A-2]. 

• Maintain a consistent collaborative session [NCOE JIC, 2005 :A-2]. 

• Provide synchronization between multiple applications with simultaneous user 
interaction [NCOE JIC, 2005 :A-3]. 

• Maintain traceability of collaborative process [NCOE JIC, 2005 :A-3]. 

• Rapidly deploy and employ robust connectivity forward [NCOE JIC, 2005 :A-16]. 

• Provide global ASW information transport services [NCOE JIC, 2005 :A-16]. 

• Establish nodes where needed [NCOE JIC, 2005 :A-16]. 

• Operate without geographic constraints [NCOE JIC, 2005 :A-16]. 

• Ensure network availability [NCOE JIC, 2005: A-15]. 

Ability to Perforin Information Operations 

• Prevent the injection of malicious functionality [NCOE JIC, 2005:A-23]. 

• Ensure that only authorized entities and valid information and services are used 
[NCOE JIC, 2005:A-23]. 

• Establish access and implement subscriber authentication [NCOE JIC, 2005 :A-9]. 

• Maintain ASW information and knowledge connectivity in limited bandwidth 
environment [NCOE JIC, 2005 :A-9]. 

• Ensure that only authorized groups and individuals can access information 
[NCOE JIC, 2005 :A-7]. 

• Ensure that hostile attacks to the environment are detected, investigated, and dealt 
with appropriately [NCOE JIC, 2005: A-10]. 

• Assure information [NCOE JIC, 2005: A-10]. 

• Validate critical and valuable information [NCOE JIC, 2005:A-11]. 

• Determine and maintain an information pedigree [NCOE JIC, 2005:A-11]. 

• Securely label data and information consistent with information assurance 
guidelines [NCOE JIC, 2005:A-11]. 

• Authenticate identity [NCOE JIC, 2005:A-27]. 

• Verify identity of information and service provider or requestor [NCOE JIC, 
2005:A-28]. 

• Protect in-transit information [NCOE JIC, 2005:A-29]. 
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• Identify mission criticality or friendly systems and nodes [NCOE JIC, 2005 :A- 
29], 

• Track DoD information flow [NCOE JIC, 2005:A-29]. 

• Electronically map networks in which DoD information traverses [NCOE JIC, 
2005:A-29]. 

• Perform continuous network defense [NCOE JIC, 2005:A-29]. 

• Employ tiered, defense in-depth protection across the NCOE [NCOE JIC, 
2005:A-30]. 

• Deter, detect, and deny unauthorized intrusions to the NCOE [NCOE JIC, 
2005:A-31]. 

• Deter, detect, and deny unauthorized insider access to the NCOE [NCOE JIC, 
2005:A-31]. 

• Identify network intrusions and probing attempts [NCOE JIC, 2005:A-31], 

• Provide cyber situational awareness and network defense [NCOE JIC, 2005 :A- 
31], 

• Investigate security events and incidents to determine cause, impacts, and 
response options [NCOE JIC, 2005:A-31]. 

• Assess operational impact of attacks [NCOE JIC, 2005:A-31]. 

• Characterize the current threat to network environment [NCOE JIC, 2005:A-31]. 

• Report on characterization of attack elements [NCOE JIC, 2005:A-32]. 

• Respond to network attacks and intrusions with appropriate actions [NCOE JIC, 
2005:A-32]. 

• Share information assurance and computer network defense situation awareness 
information with authorized users [NCOE JIC, 2005:A-32]. 

• Conduct vulnerability assessments and evaluations [NCOE JIC, 2005:A-32]. 

• Employ security patches [NCOE JIC, 2005:A-15]. 

• Channel the attacker [NCOE JIC, 2005:A-15]. 

• Isolate compromised network nodes [NCOE JIC, 2005: A-16]. 

• Synchronize defense operation across DoD and with coalition partners [NCOE 
JIC, 2005 :A-16], 

• Replicate information systems and information infrastructures through modeling 
and simulation [NCOE JIC, 2005 :A-16], 

• Perform forensic analysis to establish the facts or evidence surrounding security 
events and incidents [NCOE JIC, 2005 :A-16]. 

• Provide network situational awareness [NCOE JIC, 2005 :A-17], 

• Maintain network capabilities and ensure survivability [NCOE JIC, 2005 :A-17], 

• Minimize packet loss in a hostile environment [NCOE JIC, 2005 :A-17], 

• Maintain service under physical and information attack [NCOE JIC, 2005 :D-10], 

• Degrade gracefully 

• Utilize dynamic rerouting 

Ability to Optimize Network Functions and Resources 

• Ensure spectrum availability to satisfy operational requirements [NCOE JIC, 
2005:A-17]. 


204 





• Manage and configure systems and networks [NCOE JIC, 2005 :A-17], 

Ability to Transport ASW Information from End-to-End 

• Transmit ASW information [NCOE JIC, 2005 :A-17]. 

• Receive ASW information [NCOE JIC, 2005 :A-17], 

• Automatically implement service prioritization [NCOE JIC, 2005 :A-17], 

• Deliver ASW information [NCOE JIC, 2005:A-17]. 

Ability to Provide ASW Data and Information Management 

• Interact effectively with collaborative tools in a cooperative environment [NCOE 
JIC, 2005:A-18], 

• Develop a parallel process for monitoring an understanding the operational 
environment and synchronizing actions of assigned forces [NCOE JIC, 2005 :A- 

4]. 

• Provide visualizations of non-visible phenomena by synthetic means for COI 
purposes and threat awareness [NCOE JIC, 2005 :A-18], 

• Present ASW data from multiple enterprise sources in a humanly intelligible, 
timely, and fused format [NCOE JIC, 2005 :A-5]. 

• Identify selection criteria and assess alternatives to decisively control operational 
situations through automation in exchange, fusion, and understanding of ASW 
information [NCOE JIC, 2005:A-5]. 

• Achieve situational awareness using geospatial and time-centric displays of 
enterprise-wide data to relate information with similar characteristics [NCOE JIC, 
2005:A-5]. 

• Simultaneously process inputs from multiple sources and retain focus on the task 
at hand [NCOE JIC, 2005 :A-19], 

• Limit the sharing of situational understanding to authorized individuals and to 
only accept situation updates from authoritative sources [NCOE JIC, 2005:A-23]. 

• Connect and interface with interagency and coalition [NCOE JIC, 2005 :A-7]. 

• Share across security areas such as coalitions such as Homeland Security [NCOE 
JIC, 2005:A-7]. 

• Enable machine-to-machine info-sharing [NCOE JIC, 2005 :A-7]. 
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• Provide relevant ASW information based on users roles and responsibilities 
[NCOE JIC, 2005 :A-7]. 

• Manage ASW data and information life cycle and optimize ASW data and 
information handing [NCOE JIC, 2005 :A-7]. 

• Enable smart pull and push ASW information [NCOE JIC, 2005 :A-8]. 

• Perform intelligent search [NCOE JIC, 2005 :A-8]. 

• Determine the sensitivity of the ASW information being requested [NCOE JIC, 
2005:A-24]. 

• Integrate and fuse ASW data [NCOE JIC, 2005:A-10], 

• Maintain confidence in the authority of the information and services received and 
the authorization of the consumers of those information and services [NCOE JIC, 
2005: A-10], 

• Enable sharing of the enterprise information resources and enterprise process and 
applications [NCOE JIC, 2005: A-10]. 

• Provide accurate and relevant ASW data [NCOE JIC, 2005:A-10]. 
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APPENDIX C. VALUE HIERARCHY STAKHOLDER SURVEY 


From: Naval Postgraduate School, Master’s of Science Systems Engineering, Cohort 
311-071 

To: Anti-Submarine Warfare Community of Interest Stakeholders 

Subject: STAKEHOLDER SURVEY OF VALUE HIERARCHY 

Enclosure: 

(1) Anti-Submarine Warfare C4I Value Hierarchy 

(2) Value Hierarchy Glossary 

(3) Stakeholder Survey 


1. This memorandum requests your participation in evaluating and completing our Value 
Hierarchy. The purpose of a Value Hierarchy is to reflect the critical values of the 
stakeholders by expanding the effective need of a system into critical functions, sub¬ 
functions and objectives. The Value Hierarchy then attempts to quantify the relative 
value placed on those critical functions, sub-functions and objectives by the stakeholders. 
The critical functions, sub-functions, objectives and evaluation measures are shown 
graphically in Enclosure 1. A glossary that defines each of the critical functions, sub¬ 
functions, objectives and evaluation measures is found in Enclosure 2. Enclosure 3 is the 
actual survey we are requesting you to fill out. The intent of the survey is to ascertain 
relative value, identify the most critical sub-functions and to gain feedback on the 
proposed evaluation measures. 


2. The first goal of the survey is to compare entries at the same tier that also share the 
same parent in terms of relative importance to the stakeholder. We are utilizing the 
following numerical-based scale of 1 to 5: 

• 1 - “much less” value 

• 2 - “less” value 

• 3 - “the same” value 

• 4 - “more” value 
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• 5 - “much more” value 


The survey is intentionally very qualitative and subjective in nature. Please ensure you 
provide a relative rating for each entry in a table. Each table is to be treated 
independently. A few notes to consider. As an example, if a tier has 4 functions that 
share the same parent and you rank them all a 5, that tells us that while you place a lot of 
value on them all, you also view them as equal to each other on a relative basis. 
Normalizing that input would make the score a three since they are all equal to each 
other. To expound on the example a little more, if you rate them all a five but the parent 
is ranked a one relative to its peer(s) then you would be sending a very conflicting 
message to us. If the sub-functions are viewed as providing ‘much more’ value, then 
consistency in that view should mean the parent also should likely show ‘much more’ 
value or ‘more’ value. 


The second goal of the survey is to have you rank order the top five sub-functions. 
Enclosure 3 has a table listing all the sub-functions that have evaluation measures. All 
that is requested is that you rank order what you believe are the top 5. 


The final goal is to solicit feedback on the provided evaluation measures in terms of 
validity of the proposed measure and inputs regarding threshold and objective values. 
Please take the time to look at Enclosure 1 and read through Enclosure 2 from which to 
formulate your comments back to us. 


3. Your time and effort in completing this survey are greatly appreciated. If you have 
any questions, please email me at maletour@nps.edu . We look forward to receiving your 
responses by email (preferably) or FAX no later than 23 May, 2008. Emails can be sent 
to me at maletour@nps.edu and you can FAX me at 760-633-3536. 

Very Respectfully, 


Matt LeToumeau, CDR, USN 
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Scale: 1 - Much Less; 2 - Less; 3 - The Same; 4 - More; 5 - Much More 

(Remember to fill in eaeh table eompletely and treat each table independently) 


Tier 1 - Parent is AO (ASW Net-Centric C4I System) 


Critical Element 

Score 

System Performance 


System Availability 



Tier 2 - Parent is System Performance 


Critical Element 

Score 

A. 1 Provide Connectivity 


A.2 Perform Information Operations 


A.3 Optimize Network Functions and Resources 


A.4 Transport ASW Information from End-to-End 


A. 5 Provide ASW Data and Information Management 



Tier 2 - Parent is System Availahility 


Critical Element 

Score 

Provide Reliability 


Provide Availability 


Provide Maintainability 



Tier 3 - Parent is A.l (Provide Connectivity) 


Critical Element 

Score 

A. 1.1 Interconnect Communication Nodes 


A. 1.2 Interface with ASW Sensor and ASW Weapon Systems Data 

Streams 


A. 1.3 Connect and Interface with External Networks 



Tier 3 - Parent is A.2 (Perform Information Operations) 


Critical Element 

Score 

A.2.1 Provide Computer Network Defense 


A.2.2 Provide Electronic Protection 


A.2.3 Provide Information Assurance (lA) 


A.2.4 Provide Physical Security 



Tier 3 - Parent is A.3 (Optimize Network Functions and Resources) 


Critical Element 

Score 

A.3.1 Manage and Control Network 


A.3.2 Manage Spectrum 


Tier 3 - Parent is A.4 (Transport ASW Information from End-to-End) 

Critical Element 

Score 
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A.4.1 Transmit ASW Information 


A.4.2 Deliver ASW Information 


A.4.3 Receive ASW Information 



Tier 3 - Parent is A.5 (Provide ASW Data and Information Management) 


Critical Element 

Score 

A.5.1 Fuse ASW Data 


A.5.2 Provide ASW COTP 


A.5.3 Identify, Store, Share and Exchange ASW Data and Information 



Tier 4 - Parent is A.5.3 (Identify, Store, Share and Exchange ASW Data and 
Information 


Critical Element 

Score 

A.5.3.1 Transfer ASW Data from Machine to Machine 


A.5.3.2 Provide ASW Information Publish and Subscribe Services 


A.5.3.3 Manage ASW Data and Information Life Cycle and Optimize 

ASW Data and Information Handling 


A.5.3.4 Enable Smart Pull and Push of ASW Information 



Top Five Evaluated Sub-Functions 


(Please Rank Order Your Top Five Using 1-5) 


Critical Element 

Rank 

A. 1.1 Interconnect Communication Nodes 


A. 1.2 Interface with ASW Sensor and ASW Weapon Systems Data 

Streams 


A. 1.3 Connect and Interface with External Networks 


A.2.I Provide Computer Network Defense 


A.2.2 Provide Electronic Protection 


A.2.3 Provide Information Assurance (lA) 


A.2.4 Provide Physical Security 


A.3.1 Manage and Control Network 


A.3.2 Manage Spectrum 


A.4.1 Transmit ASW Information 


A.4.2 Deliver ASW Information 


A.4.3 Receive ASW Information 


A.5.1 Fuse ASW Data 


A.5.2 Provide ASW COTP 


A.5.3.1 Transfer ASW Data from Machine to Machine 


A.5.3.2 Provide ASW Information Publish and Subscribe Services 


A.5.3.3 Manage ASW Data and Information Life Cycle and Optimize 

ASW Data and Information Handling 


A.5.3.4 Enable Smart Pull and Push of ASW Information 
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APPENDIX D. EVALUATION MEASURES 


A1 - Provide Connectivity 
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Figure 67. Value System A1 - Objectives and Evaluation Measures 

This figure represents the Provide Connectivity function and its sub-functions along with the 

objectives and evaluations measures. 

The evaluation measure for funetion A. 1.1, “Intereonnect Communieation 
Nodes,” is the time it takes a node to join the network, and the unit of measure is seconds. 
This evaluation measure was chosen because in a NCOE it is essential that a node join 
the network and start participating in information exchange to establish a common 
situational awareness. This function supports the NCOE Network Management 
capability. The objective is to “Minimize Network Join Time.” 

The evaluation measure for function A. 1.2, “Interface with ASW Sensor and 
ASW Weapon Systems Data Streams,” is the number of data streams provided divided by 
the number of streams available, and the unit of measure is percentage. This measure is 
an indication of the “nettedness” of the sensors and weapons and provides the operator 
with the ability to match weapons with sensors to maximize their effectiveness. This 
function supports the NCOE Knowledge Management capability. The objective for this 
measure is to “Maximize Interfaces to External Data Streams”. 
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The evaluation measure for funetion A. 1.3, “Conneet and Interface with External 
Networks,” is “Net Ready Compliance,” and the unit of measure is percent (%). The 
measure ““Net Ready Compliance” is an evaluation of net ready key performance 
parameters and an indicator of net-centricity. Two of the elements that make up the net 
ready key performance parameters are GIG Key Interface Profiles (KIP) and Net-Centric 
Operations and Warfare (NCOW) Reference Model (RM). An example of GIG KIP is a 
mission critical interface or an interface that affects multiple programs. The NCOW RM 
describes the set of activities comprising a net-centric environment, such as core services 
and enterprise management. Compliance with GIG KIPs and NCOW RM is 
demonstrated by analysis of systems engineering specification documents and 
interoperability testing. This function supports the NCOE Knowledge Management 
capability. The objective for this measure is “Maximize GIG Connectivity.” 
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A2 - Perforin Information Operations 
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Figure 68. Value System A2 - Objectives and Evaluation Measures 

This figure represents the Information Operations function and its sub-functions along with the 

objectives and evaluations measures. 

The evaluation measure for function A.2.1, “Provide Computer Network 
Defense,” is the fraction of network nodes protected by computer network defense 
appliances, such as intrusion detection systems, firewalls, and malicious software 
scanners. The unit of measure is percent (%). These appliances automatically and 
continuously scan, sanitize, and alert operators of potential network bom threats. This 
function supports the NCOE Information Assurance capability. The objective of this 
measure is to “Maximize Computer Network Protection.” 

The evaluation measure for function A.2.2, “Provide Electronic Protection,” is the 
fraction of communication links protected from dismption, and the unit of measure is 
percent (%). Critical communication links need to be protected from a hostile 
environment, such as jammers and electromagnetic impulse. However, not all 
communication links are critical and need protection. Protection can also be provided 
through communication diversity. The percentage of protected critical links is a measure 
of robustness of the Joint ASW C4I Architecture. This function supports the NCOE 
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Information Assurance capability. The objective of this measure is to “Minimize 
Susceptibility to Electronic Attack.” 

The evaluation measure for function A.2.3, “Provide Information Assurance,” is 
the fraction of systems in the Joint ASW C4I Architecture that have an authority to 
operate (ATO), and the unit of measure is percent (%). An authority to operate is an 
indicator of degree of compliance of a system with Department of Defense information 
assurance requirements. These requirements are stated in the DoDI 8500.1 and Depart of 
Defense Information Systems Agency (DISA) Security Technical Implementation Guides 
[STIGS, 2008]. An authority to operate is the result of completing the certification and 
accreditation activities which are described in DoDI 5200.4, Defense Information 
Technology Certification and Accreditation Process [DoDI 5200.40, 1997]. The 
DITSCAP has been superseded by the Department of Defense Information Assurance 
Certification and Accreditation Process (DIACAP) DoDI 8510.01. The objective of this 
measure is “Maximize Information Assurance Protection.” 

The evaluation measure for function A.2.4, “Provide Physical Security,” is also an 
authority to operate. The authority to operate is the result of a comprehensive evaluation 
of the technical and non-technical security requirements. Physical security falls under the 
non-technical security requirements, and the evaluation is carried out in accordance with 
DOD 5200.08-R, dated April 9, 2007. This function supports the NCOE Information 
Assurance Management capability. The objective of this measure is “Minimize 
Opportunity for Physical Intrusion and or Attack.” 
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A3 - Optimize Network 
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Figure 69. Value System A3 - Objectives and Evaluation Measures 

This figure represents the Optimize Network flinetions and its sub-functions along with the 

objectives and evaluations measures. 

The evaluation measure for funetion A.3.1, “Manage and Control Network,” is 
the fraction of bandwidth required divided by the bandwidth available, and the unit of 
measure is percent (%). Bandwidth is an indicator of quality of communication in the 
Joint ASW C4I Architecture. This frmction supports the NCOE Network Management 
capability. The objective of this function is to “Maximize the Delivery of High Priority 
Traffic.” 

The evaluation measure for function A.3.2, “Manage Spectrum,” is spectrum 
required divided by the spectrum available, and the unit of measure is percent (%). 
Spectrum is allocated by higher authority. Request for spectrum can be cumbersome and 
time consuming and not well suited for a rapidly changing networked battlespace. 
Therefore it is essential to ensure that allocated spectrum will meet or exceed spectrum 
demands and be provided in near real-time. This frmction supports the NCOE Network 
Management capability. The objective of this function is to “Maximize Spectrum 
Availability.” 
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A4 - Transport Information ASW Operations from End-to-End 
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Figure 70. Value System A4 - Objectives and Evaluation Measures 

This figure represents the Transport ASW Information End-to-End function and its sub-functions 
along with the objectives and evaluations measures. 

The evaluation measure for function A.4.1, “Transmit ASW Information,” for 
function A4.2 “Deliver ASW Information,” and for function A.4.3, “Receive ASW 
Information,” are latency and throughput, and the units of measure are time 
(milliseconds) and mega bits per second, respectively. These measures represent a 
standard measure of end-to-end delivery chain which characterizes the performance and 
quality of these functions. Latency indicates the internal processing and path delay, and 
the bandwidth measure represents the amount of information, in bits, that can be 
transmitted in one second - the “fatness of the pipe.” The objective for each of the 
functions, A.4.1, A.4.2, and A4.3, is “Maximize Transport Efficiency,” “Maximize 
Delivery Time,” and “Maximize Reception Efficiency,” respectively. 
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A5 - Provide ASW Data and Information Mana 2 einent 
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Figure 71. Value System AS - Objectives and Evaluation Measures 

This figure represents the Provide ASW Data and Information Management function and its sub¬ 
functions along with the objectives and evaluations measures. 

The evaluation measure for function A.5.1, “Fuse ASW Data,” is the amount of 
time it takes for the data fusion process to produce an output after the input is received. 
This function supports the NCOE Knowledge Management capability. The objective of 
this function is to “Minimize Data Fusion Processing Time.” 

The evaluation measure for A.5.2, “Provide ASW COTP,” is the number of users 
with access divided by the total number of users that can access the COTP, and the unit 
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of measure is pereent (%). The availability of COTP is a measure of the common 
organization situational awareness. A common situational awareness is a prerequisite for 
coordination and self synchronization in a net-centric operational environment. This 
function supports the NCOE Knowledge Management capability. The objective of this 
measure is to “Maximize availability of COTP.” 

The evaluation measure for A.5.3.1, “Transfer ASW Data from Machine to 
Machine,” is the number of systems machine-to-machine enabled divided by the number 
of systems machine-to-machine capable, and the unit of measure is percent (%). This 
measure represents the timeliness and elimination of human error in completing an 
action. This function supports the NCOE Knowledge Management capability. The 
objective of this measure is “Minimize Human in the Loop.” 

The evaluation measure for A.5.3.2, “Provide ASW Information Publish and 
Subscribe Services,” is the percent of information posted and published, and the unit of 
measure is percent (%). This evaluation measure is extracted from the NCOE JIC. 
Publish and subscribe services automate the process of sharing information as it is 
generated or updated. This function supports the NCOE Knowledge Management 
capability. The objective of this measure is to “Maximize Use of Publish and Subscribe 
Services.” 

The evaluation measure for function A.5.3.3, “Manage ASW Data and 
Information Life Cycle and Optimize ASW Data and Information Handling,” is the 
availability of data and information to the network, and the unit of measure is percent 
(%). Management of data and information encompasses a number of functions, such as 
managing storage, providing catalog service, providing search services, data 
reconciliation, database query service, data get and put functions, purging of old data, and 
data backup services. This service frees the user from mundane tasks and lets them 
concentrate on knowledge production. This function supports the NCOE Knowledge 
Management capability. The objective of this measure is to “Provide efficient data 
management services.” 

The evaluation measure for function A.5.3.4, “Enable Smart Pull and Push of 
ASW Information,” is the response time to user push and pull requests, and the unit of 
measure is time (seconds). This measure permits users to search for specific data not 
available through publish and subscribe services and to retrieve it. The users can also 
update (post) data for other users to pull from an archive or data distribution center. This 
function supports the NCOE Knowledge Management capability. The objective of this 
measure is to “Maximize Pull and Push times.” 
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AO: Non - Functional Value System Requirements 
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Figure 72. Value System AO - Objectives and Evaluation Measures 

This figure represents the non-functional branch of the decomposition and its sub-functions along 

with the objectives and evaluations measures. 

The discussion of reliability, maintainability, and availability is extracted from 
Blanchard and Fabrycky chapters 12 and 13 [Blanchard and Fabrycky, 2006: 369-449]. 
Availability is discussed last as it is derived from reliability and maintainability 
measures. 

The evaluation measures for “Provide Reliability,” are the mean time between 
failures which is the inverse of failure rate of the entity under consideration, and the unit 
of measure is time (hours). This measure was chosen based on the discussion in section 
12.2 of Blanchard and Fabrycky [Blanchard and Fabrycky, 2006: 369-449]. The 
objective of this measure is to “Maximize Reliability.” 

The evaluation measure for "Provide Supportability," is logistics delay time 
(LDT). This is the maintenance downtime that results from waiting for a spare part or 
test equipment to be available and waiting for transportation or use of a facility. This 
measure was chosen based on the discussion in section 13.2 of Blanchard and Fabrycky 
[Blanchard and Fabrycky, 2006: 430]. 

The evaluation measure for "Provide Producibility," is manufacturing lead time 
(MLT). This is the time needed for a product to be in the manufacturing process. This 
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includes time spent being processed on machines, set up requirements and time between 
processes. This measure was chosen based on the discussion in section 16.3 of Blanchard 
and Fabrycky [Blanchard and Fabrycky, 2006: 562]. 


The evaluation measure for “Provide Maintainability,” is the Mean Active 

Maintenance Time (M ). This is the average time required to perform maintenance and 
includes both scheduled and unscheduled maintenance actions. The measure is a 

function of failure rate (A.), Mean Corrective Maintenance Time ( Met ), Mean 
Preventive Maintenance Time (Mpt), and frequency of preventive maintenance per 
operational hour (fpt). Mathematically it is defined as the ratio: 

- (A)(Mct) + (fiyt)(Mpt) 

A + Jpt 

The objective of this measure is to “Minimize Maintenance Hours.” 
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APPENDIX E. DEEINITIONS AND IDEFO DIAGRAMS 


Input and Output Definitions 

Assured ASW Sensor Data - The Joint ASW C4I Architecture protects and defends 
ASW sensor data by ensuring its availability, integrity, authentication, confidentiality, 
and non-repudiation. 


Assured ASW Weapon Data - The Joint ASW C4I Architecture protects and defends 
ASW weapon data by ensuring its availability, integrity, authentication, confidentiality, 
and non-repudiation. 


Assured METOC Data - The Joint ASW C4I Architecture protects and defends 
METOC data by ensuring its availability, integrity, authentication, confidentiality, and 
non-repudiation. 


ASW Sensor Data - Raw or processed sensor data that is transmitted to the Joint ASW 
C4I Architecture by all of the ASW sensors in the network. This includes all devices that 
measure or detect real-world conditions, such as acoustic or electromagnetic sensors. 

This can also include sensor-to-sensor cueing which is transported through the Joint 
ASW C4I Architecture and sent to another sensor through ASW sensor tasking. 


ASW Sensor Tasking - Transports the ASW sensor task to the external sensors. 


ASW Sensor Tasks - The “Provide ASW Data and Information Management” function 
transmits the ASW sensor tasks to the “Transport ASW Information from End-to-End” 
function. Commands for the sensors that enable sensor resources to be dynamically 
focused on high priority sectors of the battlespace. This enables a scarce sensor resource 
to serve many customers, and helps ensure that the right mix of sensors are available at 
the right time. The operational benefit of sensor tasking is enhanced when sensors from 
multiple platforms simultaneously focus their energy on the same object. These are 
generated based on ASW sensor data or user commands. Sensor tasks can include sensor 
cueing, tracking, or battle damage assessment. 


221 



ASW Weapon Data - Weapon data that is transmitted to the Joint ASW C4I 
Architecture by all of the ASW weapon assets in the network. This includes weapon 
status and engagement status for post engagement re-evaluation. 


ASW Weapon Tasking - Transports the ASW weapon task to the external weapons. 


ASW Weapon Tasks - The “Provide ASW Data and Information Management” function 
transmits the ASW weapon tasks to “Transport ASW Information from End-to-End” 
function. These are generated based on user commands. Weapon tasks can include 
weapon control orders, weapon assignment, or weapon and target pairing. 


Bandwidth Management Plan - The plan to determine the bandwidth management 
strategy which will measure and control communications in the Joint ASW C4I 
Architecture. The bandwidth management plan will help avoid overfilling the network, 
which would result in network congestion and poor performance. 


Computer Attack - Actions taken through the use of computer networks to disrupt, 
deny, degrade, or destroy information resident in computers and computer networks, or 
the computers and networks themselves [JP 1-02, 2001: 111]. 


Defended Computer Attack - An output of the “Perform Information Operations” 
function that results in a computer attack being thwarted, negated or minimized. 


Defended Electronic Attack - An output of the “Perform Information Operations” 
function that results in an electronic attack being thwarted, negated or minimized. 


Defended Physical Attack - An output of the “Perform Information Operations” 
function that results in a physical attack being thwarted, negated or minimized. 
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External ASW Interface Connections - Establishes the network with all external 
sensors and weapons. This is established so that the Joint ASW C41 Architecture can 
interface with the external sensors and weapons so that the sensors and weapons are 
networked. 


Electronic Attack - Division of electronic warfare involving the use of electromagnetic 
energy, directed energy, or anti-radiation weapons to attack personnel, facilities, or 
equipment with the intent of degrading, neutralizing, or destroying enemy combat 
capability and is considered a form of fires [JP 1-02, 2001: 178]. The emphasis for the 
Joint ASW C41 Architecture is on the aspect of spectrum denial. 


External Network Connections - Connects the network with other networks. This is 
established so that the Joint ASW C4I Architecture can utilize other networks for 
transport and retrieval of information. 


Internal Communication Connections - Establishes the network between all internal 
nodes of the system. This is established so that the Joint ASW C4I Architecture can 
transport information from end-to-end. 


METOC Data - A term used to convey all meteorological (weather) and oceanographic 
(physical oceanography) factors as provided by service components. These factors 
include the whole range of atmospheric and oceanographic phenomena, from the sub¬ 
bottom of the earth’s oceans up to the space environment (space weather) [JP 1-02, 2001: 
338]. 


Networking Hardware - The physical equipment needed to facilitate the Joint ASW C4I 
Architecture. It includes routers, switches, access points, network interface cards, and 
other related hardware. The networking hardware is having a function performed on it 
that transforms its state. In A. 1 it goes from being a collection of individual units to a 
networked system. For A.3, the hardware is being transformed again with new policies 
for spectrum and network planning. It is not facilitating the performance of the function 
like people and support systems. It is the item being transformed. 
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Physical Attack - Physical attack disrupts, damages, or destroys targets through 
destructive power. Physical attack can also be used to create or alter adversary 
pereeptions or drive an adversary to use certain exploitable information systems [JP 3-13, 
2006: II-7]. 


Publishable ASW Information - The “Provide ASW Data and Information 
Management” function transmits the publishable ASW information to the “Transport 
ASW Information from End-to-End” funetion. The publishable ASW information ean 
range from sensor data to the COTP and is disseminated based on the commander’s 
intent. 


Published ASW Information - Distributes the publishable information to the external 
user. 


Quality of Service (QoS) Plan - The plan that allows the network to deliver traffic with 
minimum delay and maximum availability. 


Routing and Mobility Plan - The plan that determines the correet and most effieient 
cireuit path for a message. 


Subscribable ASW Information - The “Provide ASW Data and Information 
Management” function transmits the subscribable ASW information to the “Transport 
ASW Information from End-to-End” function. The subscribable ASW information can 
range from sensor data to the COTP and is disseminated based on user subscriptions. 


Subscribed ASW Information - Distributes the subseribable information to the external 
user. 


Transmitted ASW Sensor Data - Transmits the ASW sensor data through the Joint 
ASW C4I Arehitecture to the “Provide ASW Data and Information Managemenf ’ 
funetion for proeessing. 
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Transmitted ASW Weapons Data - Transmits the ASW weapons data through the Joint 
ASW C4I Arehitecture to the “Provide ASW Data and Information Management” 
funetion for proeessing. 


Transmitted METOC Data - Transmits the METOC data through the Joint ASW C4I 
Arehitecture to the “Provide ASW Data and I n f ormation Management” function for 
processing. 


Transmitted User Commands - Transmits the user commands through the Joint ASW 
C4I Architecture to the “Provide ASW Data and Information Management” function for 
processing. 


Transmitted User Information Reqnests - Transmits the user information requests 
through the Joint ASW C4I Architecture to the “Provide ASW Data and Information 
Management” function for processing. 


User Commands - An instruction given by the user that needs to be transported to the 
appropriate external or internal asset. User commands can include cueing the sensors, 
target nomination, threat evaluation, and weapon assignment. 


User Information Reqnest - This is a request for specific information from the user. It 
can be returned to the user through published information or smart pull of information. 


User Subscriptions - Users request to receive or obtain frequent updates on specific 
information. 
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Subfunction Definitions 

A.l.l - Interconnect Communication Nodes: This function ensures connectivity 
amongst all participating network nodes and defines a routing scheme. The more 
efficient the Joint ASW C4I Architecture network’s nodes work together, the more the 
network can utilize its collective resources [NCOE JIC, 2005:8], 


A.1.2 - Interface with ASW Sensor and ASW Weapon Systems Data Streams: This 
function establishes the connection between the Joint ASW C4I Architecture, the sensors, 
and the weapon systems. This includes ensuring that data and information generated by 
weapons and sensor systems can be provided to the communication nodes for further 
transport, translation, or modification. 


A.1.3 - Connect and Interface with External Networks: This function includes 
establishing the physical layer connection that allows the Joint ASW C4I Architecture 
access and use other external networks. 


A.2.1 - Provide Computer Network Defense: JP 3-13 defines computer network 
defense as, “actions taken through the use of computer networks to protect, monitor, 
analyze, detect and respond to unauthorized activity within Department of Defense 
information systems and computer networks” [JP 3-13, 2006: GL-5]. In the Joint ASW 
C4I Architecture, this function includes monitoring the situational awareness of the 
network and identifying when unauthorized users attempt to gain access. It also includes 
providing network security measures to ensure network integrity. 


A.2.2 - Provide Electronic Protection: JP 3-13 defines electronic protection as, “That 
division of electronic warfare involving passive and active means taken to protect 
personnel, facilities, and equipment from any effects of friendly or enemy employment of 
electronic warfare that degrade, neutralize, or destroy friendly combat capability” [JP 3- 
13, 2006: GL-7]. In the Joint ASW C4I Architecture, this function establishes protection 
of the use of the electromagnetic spectrum. 
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A.2.3 - Provide Information Assurance: JP 3-13 defines information assurance as, 
“Measures that protect and defend information and information systems by ensuring their 
availability, integrity, authentication, confidentiality, and nonrepudiation. This includes 
providing for restoration of information systems by incorporating protection, detection, 
and reaction capabilities” [JP 3-13, 2006: GL-9]. In the Joint ASW C4I Architecture, this 
function includes the protection of sensitive information by enabling confidentiality, 
authentication, integrity, non-repudiation, and availability. Confidentiality is the need to 
ensure that information is accessed, used, copied, or disclosed by users who have been 
authorized and have a genuine need. Authentication is a security measure designed to 
establish the validity of a transmission, message, or originator. Integrity means data 
cannot be created, changed, or deleted without proper authorization. Non-repudiation is 
the method by which the sender of data is provided with proof of delivery and the 
recipient is assured of the sender’s identity, so that neither can later deny having 
processed the data [Texas State Library and Archives Commission, 2008]. Availability 
means that the information and systems used to process the information are all available 
when the information is needed. 


A.2.4 - Provide Physical Security: JP 3-13 defines physical security as, “That part of 
security concerned with physical measures designed to safeguard personnel; to prevent 
unauthorized access to equipment, installations, material, and documents; and to 
safeguard them against espionage, sabotage, damage, and theft” [JP 3-13, 2006: GL-9]. 

In the Joint ASW C4I Architecture, this function establishes the physical protection of the 
information and the information infrastructure. 


A.3.1 - Manage and Control Network: This function includes managing and 
controlling the network to ensure that the greatest capability is provided to the warfighter. 
This means monitoring, tuning, repairing, and optimizing the network to meet their 
needs. The network must be able to maintain service through both physical and 
information attack. When system or equipment has been destroyed or damaged, the 
network should continue operations at a gradually reduced capacity in accordance with 
prioritization plans. It must be capable of dynamically rerouting services when nodes 
become incapacitated or information flow requirements change. To maintain or increase 
capacity, the network must be capable of obtaining additional resources as required 
[NCOE JIC, 2005 :D-10]. 
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A.3.2 - Manage Spectrum: The function includes managing a spectrum that is capable 
of operating regardless of the radio frequency spectral environment. Furthermore, the 
network must be able to dynamically allocate resources to support all operations and 
transitional states along the range of military operations [NCOE JIC, 2005: D-9]. 


A.4.1 - Transmit ASW Information: This function includes the ability of a 
communication node to send out data or information based on a user’s command. This 
function is an internal network function and is similar to placing a piece of mail in the 
mailbox. This function is responsible for transmitting user information requests, user 
commands, METOC data, ASW Weapons Data, and ASW Sensor Data internally 
throughout the Joint ASW C4I Architecture. 


A.4.2 - Deliver ASW Information: This function includes the ability of the network to 
actually deliver the data or information to a destination where someone else can receive 
it. This function is an internal network function and is similar to the mailman retrieving a 
piece of mail from one mailbox and delivering it to another. 


A.4.3 - Receive ASW Information: This function includes the ability of a 
communication to receive data or information based on a user’s command. This function 
is an internal network function and is similar to retrieving a piece of mail from your 
mailbox. This function is responsible for providing the ASW Weapon Tasking to the 
weapons, ASW Sensor Tasking to the sensors, and Subscribed and Published ASW 
Information to Users. Ultimately, it is responsible for providing information to the 
external systems. 


A.5.1 - Fuse ASW Data: This function refers to the process of gathering data from 
multiple sources and combining that data into a single source of information. The 
detailed description of the data fusion process can be found in the modeling and 
simulation section. 


A.5.2 - Provide ASW COTP: This function incorporates the display of information into 
a single identical display of relevant tactical or operational information which is shared 
by multiple users. At the tactical level this can include location, identification, intentions. 
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track history and track vector of hostile, friendly and unknown tracks of interest as well 
as items that may affect tactical decision making such as meteorological and 
oceanographic data and systems status tracks of interest. At the operational level this can 
include ever 5 dhing at the tactical level in addition to other sources of information relevant 
at the operational level, such as intelligence, logistics, rules of engagement, and 
Commander’s intent. 


A.5.3 - Identify, Store, Share and Exchange ASW Data and Information: This 
function includes all actions necessary to store, publish, and exchange information and 
data. Data must be appropriately identified and labeled (tagged), placed in a database or 
other data and information repository, and its presence announced to those who need it 
(post, publish, or advertise) [NCOE JIC, 2005: 43]. 


A.5.3.1 - Transfer ASW Data from Machine to Machine: This function includes all of 
the activities that occur when sending the data from one machine to another and is meant 
to remove the human from the loop to avoid transcription errors. An example would be 
target coordinates are generated at some command center, transmitted from that machine 
over the Joint ASW C41 Architecture’s network to a receiving communication node 
which through its interface to a weapons system sends the coordinates straight to the 
weapon system without a human needing to enter them manually. The human can still 
approve or disapprove but the transfer of the data requires no human to act as middleware 
between the machine that generated the data and the machine that will utilize the data. 


A.5.3.2 - Provide ASW Information Publish and Subscribe Services: This function 
allows the users to find and access relevant information and publish or subscribe the 
information to those who need it. Publish is exposing the information they produce for 
other to discover [NCOE JIC, 2005: E-13]. Subscribing allows users to select from a 
source of information and receive updates on a regular basis or when events occur. 


A.5.3.3 - Manage ASW Data and Information Life Cycle and Optimize ASW Data 
and Information Handling: This function includes a comprehensive approach to 
managing the flow of data and information from receipt and initial storage to the time 
when it becomes obsolete and is deleted. 
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A.5.3.4 - Enable Smart Pull and Push of ASW Information: This function includes 
the ability to distribute information through either smart pull or smart push. Smart push 
is the ability to gather information, process that information, and make decisions on who 
should receive it. Smart pull allows the warfighters to grab the information that is 
needed, regardless of where they are located. 
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Figure 73. IDEFO A1 Diagram 

This figure displays the Joint ASW C4I Architecture A1 diagram which is detailed drill of the 
Provide Connectivity function (A.l) and it shows the transformation of inputs to outputs by the 
system. 
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Figure 74. IDEFO A2 Diagram 

This figure displays the Joint ASW C4I Architecture A2 diagram which is detailed drill of the 
Perform Information Operations function (A.2) and it shows the transformation of inputs to 
outputs by the system. 
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Figure 75. IDEFO A3 Diagram 

This figure displays the Joint ASW C4I Architecture A3 diagram which is detailed drill of the 
Optimize Network Functions and Resources function (A.3) and it shows the transformation of 
inputs to outputs by the system. 



Figure 76. IDEFO A4 Diagram 

This figure displays the Joint ASW C4I Architecture A4 diagram which is detailed drill of the 
Transport ASW Information from End-to-End function (A.4) and it shows the transformation of 
inputs to outputs by the system. 
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Figure 77. IDEFO A5 Diagram 

This figure displays the Joint ASW C4I Architecture A5 diagram which is detailed drill of the 
Provide ASW Data and Information Management function (A.5) and it shows the transformation 
of inputs to outputs by the system. 
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APPENDIX F. COMPLETE FUNCTIONAL FLOW BLOCK 

DIAGRAM 



Figure 78. Functional Flow Block Diagram 

This figure displays the Joint ASW C4I Architecture completed enhanced functional flow block 
diagram which shows how the system performs its functions. 
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APPENDIX G. JOINT ASW C4I ARCHITECTURE BASELINE 

NODE CONFIGURATIONS 


SENSORS USER GROUPS DISTRIBUTION AND SWITCHING RF DISTRIBUTION 



Figure 79. T-AGOS Class C4I Baseline 

This figure is the expansion of the T-AGOS node in Figure 22 of the alternatives section of this 
report. This figure is representative of the systems that exist on an Ocean Surveillance Ship that are 
used in the execution of anti-submarine warfare. 
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Figure 80. P-3C Orion Communications Baseline Flow Diagram 

This figure is the expansion of the P-3C Orion node in Figure 22 of the alternatives section of this 
report. This figure is representative of the systems that exist on P-3C Orion aircraft that are used in 
the execution of anti-submarine warfare. 
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Figure 81. E-2C Hawk Eye Communications Baseline Flow Diagram 

This figure is the expansion of the E-2C node in Figure 22 of the alternatives section of this report. 
This figure is representative of the systems that exist on E-2C Hawk Eye aircraft that are used to 
assist in the execution of anti-submarine warfare. 
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Figure 82. RC-135VAV Rivet Joint Communications Baseline Flow Diagram 

This figure is the expansion of the RC-135V/W node in Figure 22 of the alternatives section of this 
report. This figure is representative of the systems that exist on RC-135 Rivet Joint aircraft that are 
used in the execution of anti-submarine warfare. 
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Figure 83. EP-3E Aries II Communications Baseline Flow Diagram 

This figure is the expansion of the EP-3E node in Figure 22 of the alternatives section of this report. 
This figure is representative of the systems that exist on EP-3E Aries II aircraft that are used to assist 
in the execution of anti-submarine warfare. 
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Figure 84. F/A-18E/F Super Hornet Communications Baseline Flow 
Diagram 


This figure is the expansion of the FA-18 node in Figure 22 of the alternatives section of this 
report. This figure is representative of the systems that exist on F/A-18E/F Super Hornet aircraft 
that are used to assist in the execution of anti-submarine warfare. 
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Figure 85. E-8C JSTARS Communications Baseline Flow Diagram 

This figure is the expansion of the E-8C in Figure 22 of the alternatives section of this report. This 
figure is representative of the systems that exist on E-8C JSTARS aircraft that are used to assist in 
the execution of anti-submarine warfare. 
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APPENDIX H. DETAILED SCENARIO 


Our proposed Joint ASW C4I Architecture must be responsive to real world battle 
force interactions within and exterior to its sphere of operational submarine specific 
influences. This operational scenario uses a series of vignettes to develop a Pacific 
theater maritime environment using generalized military and non-military force 
denominators to drive communication-oriented events of limited durations through 
FY2020 available communications paths. Reaction to data is of critical importance to the 
Blue Force Commander and his or her combatant forces for command and control, early 
warning, and battle readiness. Timely data delivery will determine the effectiveness and 
suitability of the network architecture and is required for the fleet to perform and 
accomplish its assigned mission tasks. Additionally, the Joint ASW C41 Architecture 
includes the difficult underwater ingredient to obtain and transmit data to submarines on 
and below the sea surface. 

The scenario outlines a finite number of key network systems identified in 
the Scenario Order of Battle, Table 15, using interactive C41 events located in four 
mission vignettes. Inputs to the Joint ASW C4I Architecture are essential for the 
assigned Undersea Warfare Commander include geography; known maritime operating 
areas; and, the expected capabilities of Red, White, and Blue Forces within the intended 
battlespace and timeframe. 

To detect and defeat Red Force threats, Blue Force sensors and weapons will be 
integrated to produce battlespace dominance on, above, and below the sea. This is 
a challenging goal. Co mm unications required between sensors and weapons 
when functioning within the littoral enviro nm ent will be extremely limited due to 
significant noise and clutter found above and trapped below the sea surface. The 
most effective approach to countering these limitations is to network large 
numbers of distributed sensors and weapon [Navy Warfare Development 
Command, 2008]. 

Geography 

Our battle space will span the oceanic and littoral areas from the South China Sea 
through the Straits of Malacca, into the Bay of Bengal, as well as, the coastal reaches of 
eastern India. Figure 86 provides a graphic depiction of India’s shallow water areas, 10 
to 1000 meters in-depth, overlaid with the economic exclusion zone (FEZ) 
[Comprehensive Swath Bathymetric Survey of Entire Indian EEZ, 2008]. The narrow 
littoral regions along India’s east coast allow for limited surface transits allowing them to 
dive much closer to the shoreline. 
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Littoral waters are eharaeterized by relatively shallow water columns 
normally adjacent to landmasses and almost always found to be noisy both acoustically 
and electromagnetically. Underwater sound including ship traffic and underwater sea life 
is trapped in this water mass. Blue Force communication nodes may receive enemy 
electromagnetic jamming activity due to their proximity to enemy shore based sites and 
most assuredly by enemy shore based aircraft. Line-of-sight communications can be 
expected between all friendly force actors and with friendly relay sites ashore. 

The deep water environment can be characterized as open, ocean with 
much less noisy conditions. It generally offers the opportunity for long range acoustic 
sound channeling to send or receive signals. Though the Blue Force nodes will have line- 
of-sight communication options with each other sheer distance requires them to have over 
the horizon reach-back capabilities to adequately carry out missions. 

Bathymetric features and water column characteristics provide the ocean’s 
framework for acoustic energy propagation ranges. Understanding dynamic ocean 
features will benefit the ASW forces in improved submarine detection, location, and 
weapons engagement. Figure 87 displays water depths for the Bay of Bengal that exceed 
3500 meters. Major weather conditions impacting operational missions in the world’s 
tropical regions are monsoonal rains and typhoons. Weather and oceanographic 
conditions need to be sensed, reported on, and modeled to provide friendly forces a 
tactical advantage over the adversary. 
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Figure 86. Economic Exclusion Zone & Shallow Water Areas 

This chart provides a simple graphic display of shallow blue areas and the solid lined economic 
exclusion zones of marshalling and security interest to India [From Global Ocean Associates, 
2004]. 


243 




Figure 87. Bathymetric Chart of Bay of Bengal 

This chart provides a simple graphic display of the depths off of eastern India showing littoral 
shallow water to be very close to shore [From Global Ocean Associates, 2004], 

Green Force Maritime Operating Areas 

India is centrally located to key Indian Ocean sea lines of communication (SLOC) 
interests between the Sea of Oman and the Straits of Malacca leading into Malaysia. Its 
maritime forces have immediate access to littoral and deep ocean waterways to enable its 
enforcement of distant, off shore SLOC and with the preservation and protection of its 
littoral, near shore EEZ. India’s Navy is principally responsible for conducting SLOC 
security in support of its import and export trade well away from the mainland. 
Surveillance and policing of the EEZ duties fall to the Coast Guard who seek to prevent 
activities spanning from offshore fishery poaching to coastal intercept of non-state, 
terrorist advances. 
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Green Force (ISR Target then Becoming Coalition Force Partner) 

The Green Foree Army and Air Foree are using terrestrial and air-based seareh 
and eommand and control systems nearest the coastal India shoreline. The Air Force is 
estimated to have 45 fixed-wing squadrons, 20 helicopter units and numerous surface -to- 
air missile squadrons, with units varying from 12 to 18 aircraft. Coast Guard units are 
conducting surveillance and C2 operations from both sea surface and air based platforms 
though limited to the bounds of the EEZ, while India’s Naval Force conducts similar 
operations from within and well beyond the EEZ in littoral and open ocean areas. The 
Navy’s subsurface submarine platform capability rounds out the maritime options. 

Figure 88 highlights three major seaports - Mombai, Cochin, and Vishakhapatnam. All 
are under intermittent Blue Force surveillance to monitor, control and hold the Green 
force maritime assets, especially its submarines, at bay. 



Figure 88. Principle Green Force Ports 

This chart offers a graphic depiction of India’s major sea ports and their proximity to the Bay of 
Bengal and Arabian Sea [About.com, 2008]. 

India’s naval forces are multi-national, mostly pre-owned, aging ships and aircraft 
originating from the United Kingdom, Russia, and the United States. Its Coast Guard 
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consists of 76 ships - 4 Advance Offshore Patrol Vessels; 9 Offshore Patrol Vessels; 11 
Fast Patrol Vessels; 13 Inshore Patrol Vessels; 2 Seaward Defense Boats; 12 Interceptor 
Boats; 8 Interceptor Vadyar Crafts; 4 Interceptor Bristol Crafts; and 6 Hovereraft; 24 
Fixed Wing (Domiers) 228 Aireraft; and, 21 helieopters - 17 Chetak and 4 Advanee 
Lightweight Helicopters) [Indian Armed Forces, 2007], Red Force naval platforms are 
estimated to be over 80 vessels with 2 aircraft carriers (additional 1 in construetion), 16 
submarines (6 under eonstruetion), 8 destroyers, 13 frigates, 24 frigates, 20 patrol eraft, 

12 minesweepers and numerous amphibious and support ships. The aircraft carriers have 
the following aviation assets: 

• Viraat (ex-Hermes) - 28 aircraft (Sea Harriers Mk51 and Mk52; H-3 Sea 
King Mk42; HAL Chetak; HAL Dhruv) 

• Vikramaditya (ex-Admiral Gorshkov) - 16 aireraft (MiG-29K; HAL Tejas; 
Sea Harrier; 6 Ka-31 ‘Helix’; HAL Dhruv) 

• Vikrant (Air Defense Ship elass under eonstruetion) - 30 aireraft (MiG- 
29K; HAL Tejas; HAL Dhruv; Ka-31 ‘Helix’) 

Green Force Communications 

India’s military forces use standard military and eommercially available 
arehitectures to address C2 and C4ISR networking requirements ineluding, but, not 
limited to [Corps of Signals, 2008]: 

• Digital, fully automated, seeure, reliable and survivable statie 
communication system based on microwave radio, optical fiber, and 
satellite and millimeter wave communieation equipments. 

• Satellite Communieations are exploiting international maritime satellites, 
and the Indian National Satellite. 

• Computer Data Networks and Information Technology are being heavily 
used for data eommunieations, weapon control and management systems. 

• Eleetronie Warfare is a potent force multiplier playing a key role in anti¬ 
insurgency and low intensity eonflict operations. 

• Cellular waveforms being used include Global System for Mobile 
communications. Code Division Multiple Aecess, Wireless Local Loop, 
mobile trunked radio, and mobile satellite systems 
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• Advanced data transmission techniques such as Synchronous Digital 
Hierarchy and Plesiochronous Digital Hierarchy are used. 

Other co mm ercial communication attributes of interest include: 

• International submarine cable systems with landing sites at Cochin, 
Mumbai, and Chennai; 

• Fiber-Optic Link Around the Globe (FLAG) at Mumbai; 

• South Africa - Far East (SAFE) site at Cochin; 

• Cable network with Singapore landing at Mumbai and Chennai; 

• Tata Indicom linking Singapore and Chennai. 

• Satellite earth stations (e.g., 8 Intelsat (Indian Ocean) and I international 
maritime satellite (Indian Ocean region); 

• 9 gateway exchanges operating from Mumbai, New Delhi, Kolkata, 
Chennai, Jalandhar, Kanpur, Gandhinagar, Hyderabad, and Emakulam. 

White Force (Commercial Merchant Ships and Airlines) 

Import and export trading relies heavily on the merchant shipping industry made 
up of over 450 ships (e.g., 101 bulk carrier, 202 cargo, 18 chemical tanker, 1 combination 
ore and oil, 9 container, 19 liquefied gas, 3 passenger, 10 passenger and cargo, 95 
petroleum tankers, and, 1 roll on and roll off) [The World Factbook, 2008]. These 
vessels represent opportunities for submarines to come and go without detection and will 
need to be positively identified as non hostile surface contacts as soon as possible in the 
kill chain process. 

Commercial airlines operating on normal international and national flight 
routes and schedules represent another entity having access to the battlespace and require 
awareness. Rapid detection, identification and deconfliction from military Red or Blue 
air assets are a must to avoid misidentification incidents and possible engagement with 
friendly aircraft. 

Red Force (Maritime Terrorist) 

Numerous third world actors have successfully obtained high performance speed 
boat and miniature submarine capabilities throughout the last decade. High performance 
speed boat numbers and their performance have continued to grow around the world 
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driven by designers and boat racing enthusiasts. This global market has been known to 
be tapped by guerilla forces in the western Pacific who have procured many for the 
conduct of their pirating operations against the world’s merchant marine fleet. Mini-subs 
have also become a worthy opponent for the continuing Global War on Terror. These 
platforms continue to turn up in drug smuggling and pirating operations around the 
world. Miniature submarine suppliers include North Korea, Iran, Germany, and Sweden. 
These miniatures have been known to operate out to ranges of 1,100 nautical miles using 
crews of two to eight. Top operational speeds average near 10 knots. Though expected 
to have high frequency communications, they are more likely to be carrying portable 
commercial satellite transmit and receive equipment to connect to worldwide internet 
protocol networks while operating on the surface at snorkel depths. Miniature 
submarines are extremely quiet, diesel and electric powered systems with very small 
surface cross sections. This capstone project design team expected them to operate solely 
in the littoral seas but they have been known to venture into blue water areas for pirating 
operations. 

Mission Vignettes - Four Phased Approach 

ASW C4I functional system requirements are motivated by ASW unique 
operational scenarios involving enemy submarine activities. The mission vignettes are 
developed using a four phased approach - Initial Preparation of the Battlespace; 

Extended Reconnaissance and Surveillance; Proactive Prosecution; and, Command 
Controlled Weapons Engagement. To accomplish each of these phases the Undersea 
Warfare Commander receives the support of the Joint ASW C4I Architecture to effect 
movement of data between manned and unmanned sensors, operational platforms, and 
weapons systems focused on the ASW problem. It is understood that the Joint ASW C4I 
Architecture must: 

• Be 99% operational for the duration of the mission vignettes. 

• Process, exploit and distribute necessary data sets. 

• Communicate 99.9% of all input sensor data to 99.9% of all intended 
system receivers. 

• Communicate all signals with 99.9% accuracy to receivers and data users. 
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Mission Threads and Assumptions have many similarities from one mission phase 
to the next and will not be duplieated. 

Mission Threads 

The Joint ASW C4I Arehitecture must aceount for mission threads falling within 
the eonduet of the Blue Foree reconnaissanee and surveillance mission scenario 
including: 

• Employ surface, subsurface, and air platforms. 

• Employ unmanned underwater vehicles. 

• Develop situational awareness of beyond line-of-sight battlespace. 

• Conduct line-of-sight and over the horizon ship maneuvering. 

• Conduct line-of-sight and beyond line-of-sight aircraft control. 

• Conduct aircraft launch and recovery of fixed and rotary wing aircraft. 

• Deploy in-situ sensors (such as sonobuoys or fixed bottom sensors). 

• Network sensed data throughout Task Group-ASW. 

• Construct common operational tactical picture. 


Assumptions 

The following assumptions have been made in constructing this vignette: 

• India remains a strong coalition partner of the United States in the Global 
War on Terror. 

• United States reconnaissance and surveillance actions are to remain as 
passive and non provocative as possible. 

• Current beyond line-of-sight C4I networks are available 75% of the time 
while operating in deep ocean areas. 

• Current beyond line-of-sight C4I networks are available 95% while 
transiting between South China Sea and Bay of Bengal battlespace. 
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• Fixed underwater surveillance systems are available and communicating 
twice weekly analyses to Task Group-ASW for inclusion in tactical 
picture from ashore location. 

• Line-of-sight communication ranges reduced to less than 7 nautical miles 
when operating in heavy seas (greater than 10 feet) and moderate to heavy 
precipitation rates. 

• Radio frequency signal jamming is not expected from Indian military 
forces. 

• Blue Force reconnaissance and surveillance mission is for intelligence 
gathering. 

• Red Force weapons engagement is not anticipated. 


Phase I - Initial Preparation of the Battlespace Vignette 

This vignette seeks to maximize the Blue Force Commander’s situational 
awareness of the intended battlespace. The Joint ASW C4I Architecture will take 
advantage of all possible sources of information including historical literature; known 
Red Force concepts of operation; tactical strategies; and, most assuredly, will seek to 
meet or exceed the Commander’s intent. The Undersea Warfare Commander will ensure 
this task is accomplished before moving into follow-on mission sets. 


Day 1 & 2 ; (Command and Control) 

Event 1: (Shore Commercial Broadcast to Surface Ships and Shore Sites using Audio and 
Video Data) International CNN news reports underwater ballistic missile testing 
observations off the coast of India. Port of Vishakhapatnam is identified as the principle 
research and development location. 


Event 2: (Local Shore to Local Shore using classified verbal and digital message) 
President orders United States National Command Authority (NCA) 30 day monitoring 
of foreign area using National Technical Means (NTM) surveillance assets and requisite 
military forces. 
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Event 3: (Shore to Overseas Shore using verbal and digital message) NCA assigns the 
Pacifie Command (PACOM) with carrying out and reporting on 30 day reconnaissance 
and surveillance mission. 


Event 4: (Overseas Shore to CVN using secure audio, video, digital data) PACOM 
assigns ASW related mission to the 7* Fleet Commander currently aboard a United 
States CVN in South China Sea. 


Event 5: (CVN to Overseas Shore using secure audio, video, digital data) 7* Fleet 
Commander requests use of his entire Blue Force Task Group for this 30 day surveillance 
mission along India’s east coast. The Task Group (TG) consists of an aircraft carrier (50 
embarked aircraft (four SH-60 ASW helicopters, two E2 Hawkeye surveillance and 44 
fighter and attack (F/A-18) fixed wing aircraft); two guided missile cruisers (two 
embarked SH-60 ASW helicopters each); one destroyer (one embarked SH-60 ASW 
helicopter); one frigate (one embarked SH-60 ASW helicopter; and two attack 
submarines (two embarked Unmanned Undersea Vehicles (UUV) each). Additionally, 
the TG will be supplemented by United States Navy electronic P-3, P-3D, United States 
Air Force RC-135 V/W (Rivet Joint) and a RC-8C (Joint Surveillance Target Attack 
Radar System (JSTARS)) aircraft stationed in Guam, and one Surveillance Towed Array 
Sensor System (SURTASS) Low Frequency Active (LFA) vessel on station in the 
Arabian Sea. Air assets will begin R&S mission support to the intended Bay of Bengal 
battlespace three days before the TG’s arrival. These aircraft will provide a maximum of 
20 hours of overlapping coverage within the operating area through the duration of the 
mission (weather permitting). 


Event 6: (CVN to Task Group using secure audio broadcast) 7* Fleet Commander orders 
“TG-ASW” to relinquish current operations and report readiness to conduct 30 day R&S 
mission within next 6 hours. 


Event 7: (CVN Onboard C2 system) 7* Fleet Commander assigns ASW mission to 
carrier based Undersea Warfare Commander (USWC) and orders the planning, 
coordination, establishment of the tactical picture, and exercise tactical control of all 
force assets versus the Red Force ASW threat in accordance with the Rules of 
Engagement within 48 hours. (Note: USWC has taken into consideration the geography 
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of the battlespace, Red Force attributes, maritime operating areas, economic exclusion 
zone, communications infrastructure, and White forces such as, merchant shipping and 
commercial air traffic provided at the top of this section.) 


Event 8: (CVN to Shore Activity using secure digital data) USWC requests additional 
digital maps and overhead imagery files of Indian ports by secure message traffic for 
delivery over next 12 hours. 


TG-ASW is 54 hours from intended battlespace in Bay of Bengal. Weather is forecasted 
to remain cloudy to partly cloudy with occasional light rain, winds from the southeast at 
10 to 20 knots. Sea heights are forecasted at 4 to 6 feet becoming 1 to 3 feet near coast. 
Sonar conditions are good for extended bottom bounce ranges. Deep sound channel is 
expected between 375 to 600 feet. 


Phase II - Extended Reconnaissance and Surveillance Vignette 

The purpose of this vignette is to delineate the operational ASW reconnaissance 
and surveillance mission requirements for the Joint ASW C4I Architecture support 
capability. The Joint ASW C4I Architecture is needed to command and control fleet 
operational maneuvers from one battlespace to another; communicate line-of-sight and 
beyond line-of-sight situational awareness of immediate and intended battlespace; 
communicate all source situational awareness of a specified Red Force seaport to 
operational afloat Task Force and a myriad of ashore staffs; and, coordinate coalition 
force command and control to reposition both naval battle groups against a new enemy. 
Ships, submarines, aircraft, and national assets, will ensure “unblinking eye” surveillance 
of India’s port of Vishakhapatnam throughout the conduct of this operational scenario. 


Day 3 -17 ; (Conduct R&S; Develop, Maintain Common Operational Picture) 

Task Group-ASW is operating within Bay of Bengal battlespace. 


Event 1: (Shore Commercial Broadcast to Surface Ships and Shore Sites using audio and 
video data) International news reports return of India Kilo class submarine after testing 
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mission. News channel available 24 hours a day though there appears to be a 4 hour 
delay in normal reporting. 


Event 2: (Shore Activity to CVN using imagery analysis, graphic and alphanumeric data) 
NTM surveillance assets confirm news reports and confirms Red Force naval assets in 
port Vishakhapatnam at 5 submarines (2 in dry-dock), 1 Aircraft Carrier (believed the 
former Soviet ship Admiral Gorshkov), and several corvettes. Updates are received 
every three hours. 


Event 3: (DDG, FFG, and SURTASS to CVN using alphanumeric and digital data) 
Surface ships communicate sensed data from 20 to 40 mile standoff ranges. All systems 
remain operational. 


Event 4: (Aircraft to CVN using alphanumeric and digital data) (E2 communicate 
standoff electronic and signals intelligence (ELINT and SIGINT) range of 60 to 80 miles 
at an altitude of 25,000 to 37,000 feet. 


Event 5: (Aircraft to CVN and Shore Activities using radar, alphanumeric and digital 
data) Air Force’s Rivet Joint and JSTARS remain on station in southern battlespace and 
confirm Red Force underway activity. 


Event 6: (Aircraft to CVN using audio, video and digital data) TG-ASW receives hourly 
report from electronic P-3 audio and video signals while flying over international waters 
of the Bay of Bengal from line-of-sight to 25 nautical miles standoff from India coast. 
Sonobuoys are deployed for use throughout 20 overlapping mission as coordinated and 
controlled by USWC or onboard P-3 operators as necessary to eavesdrop on possible 
underwater contacts. USWC notes heavy merchant ship traffic making submarine 
finding and tracking difficult if used as a screen. 


Event 7: (Aircraft to any and all surface ships using alphanumeric and digital data) 
Routine flight operations continuing. Helicopters conduct line-of-sight SONAR dipping 
operations. USWC issues operating intentions for TG-ASW platform stations and 
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frequency of helicopter operational use around NATOPS routine maintenance schedules. 
Each ship is expected to have one helicopter available 12 hours per day. 


Event 8: (Submarine to Overseas Shore Activity and CVN using secure alphanumeric and 
digital burst data) Blue Force submarines report all systems operational, maintaining 
underwater passive surveillance, deployed fixed bottom sensors nearest main shipping 
channel, and conducting normal beyond line-of-sight communications. They report all 
conditions normal and have updated latest common tactical picture. All surface and 
subsurface contacts and plot data have been transmitted for last 24 hours. 


Weather begins to deteriorate on Day 15 with easterly gale force winds and seas in excess 
of 10 feet. Heavy precipitation and monsoonal conditions expected to persist next 5 days. 

Phase III - Proactive Prosecution 

This phase offers the Joint ASW C41 Architecture the opportunity to support the 
detection and location of Red Force surface and subsurface contacts using signals 
originating from unmanned underwater sensors; air, sea, and land reporting sites. This 
phase has a communication twist to it with the need to establish coalition force 
communications with the very Red Force assets friendly forces have been maintaining 
tracks on. 


Day 18 - 25 : (Red Force Detection and Location) 

Poor weather continues into Day 20 though moving slowly northward with 
easterly gale force winds and seas in excess of 10 feet. Forecast for improved conditions 
with light winds and 3 to 5 foot seas. No precipitation expected over next 96 hours. 
USWC recommends move TG-ASW northward and reset all R&S missions at 0600, Day 
21 


Event 1: (Shore Commercial Broadcast to Surface Ships and Shore Sites using audio and 
video data) International news reports monsoonal conditions beginning to reach into 
Eastern India. India merchant ships reported overdue. India’s President expresses 
concern over missing seamen. 
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Event 2: (Shore Aetivity to CVN using secure imagery analysis, alphanumeric and 
digital graphic data) NTM surveillance (every 3 hours) - Kilo class submarine and 
Aircraft carrier appear to be readying for sea. 


Event 3: (CVN to TG-ASW and Aircraft Overseas Shore Sites using secure traffic) Blue 
Force surface and aircraft R&S operations aborted during weather event. 


Event 4: (Shore Activity to CVN using secure imagery analysis, alphanumeric and 
digital graphic data) NTM surveillance (every 3 hours) - data received indicates Kilo 
class submarine and Aircraft carrier may have been moved to safer harbor due to storm 
force winds and heavy seas. 


Event 5: (Shore Commercial Broadcast to Surface Ships and Shore Sites using audio and 
video data) International news reports monsoonal conditions have moved over 
Northeastern India and Bangladesh. India merchant ships reported taken by pirate 
activity in Straits of Malacca. India’s President wants answers. 


Event 6: (Submarine to Overseas Shore Activity and CVN using alphanumeric and digital 
data) Submarines report bottom sensors have identified Indian Kilo submarine and large 
surface contact both submarines are following from safe distance. Bottom acoustic 
sensor devices picked up multiple contacts over night. Indications are that a Kilo 
submarine moved eastward through the channel at 0100 followed by large ship at 0200. 
Submarines had to move south to communicate on surface and lost positive contact with 
Indian vessels. Seas reported rough at 6 to 8 feet. 


Event 7: (Aircraft to CVN using radar, alphanumeric and digital data) Air Force Rivet 
Joint and JSTARS report submarine and large surface contact at mouth of Red Force 
harbor heading east southeast at 10 knots. 
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Event 8: (Aircraft to CVN using audio, video, and digital data) TG-ASW receives last P- 
3 reports before being weathered out, confirming underway activity of Red Force Kilo 
submarine and aircraft carrier. 


Event 9: (CVN to TG-ASW using audio, video and digital data) Surface and aircraft R&S 
operations resumed on Day 21 with orders to locate Indian Kilo submarine from a 
distance. 


Event 10: (Ships to CVN; Aircraft to CVN; and SURTASS to Overseas Shore to CVN 
using audio, video, graphic digital data) Surface, aircraft, and SURTASS R&S operations 
confirm India’s aircraft carrier is underway at 30 knots and not attempting to avoid 
United States maritime activities. Indian aircraft reported to have made radio contact 
with United States forces to dialog about weather and if the United States had any reports 
of pirated merchant ships. 


Event 11: (SURTASS to Overseas Shore Activity to CVN using secure graphic and 
alphanumeric data) USWC receives lUSS shore station report with Kilo track 
information. 


Event 12: (Shore Commercial Broadcast to Surface Ships and Shore Sites using audio 
and video data) CNN International reported several Indian merchant ships being attacked 
by pirates while exiting the Straits of Malacca. These vessels were alleged to have 
valuable missile cargo onboard and their loss would be devastating to India and of 
extreme value to non-state terrorist actors. 


Event 13: (Pentagon to CVN using secure audio, video, digital data) TG-ASW 
Commander received time critical message: “American Ambassador to India asked if US 
could provide necessary national and naval support to assist Indian naval forces in 
recovering missing cargo and merchant ships. National Command Authority has 
modified surveillance orders to conduct joint coordinated Indian Navy and United States 
Navy operations to recover ships and cargo. Coordinate on scene with Indian 
Commander to make best operational speed to area around Straits of Malacca; conduct 
joint coordinated operations with Indian Navy assets; and, recover Indian merchant ships. 
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Event 14: (Shore Activity to CVN using secure imagery analysis, alphanumeric and 
digital graphic data) All source intelligence information identified 2 mini-submarines 
maneuvering on surface at 0300 Pacific local time about 60 miles from last known 
position of Indian merchant ships. 


Event 15: (Shore Activity to CVN using secure audio, video, digital data) NCA 
conducted secure video teleconference with TG-ASW and USWC confirmed mini¬ 
submarines and ordered Coalition naval force, led by TG-ASW, to conduct Command 
Controlled Weapons Engagement to avoid international embarrassment. 


Phase IV - Command Controlled Weapons Engagement 

United States and Indian Coalition Force successfully detects and locates two 
mini-submarines maneuvering near the Straits of Malacca. USWC intent is to force mini¬ 
submarines to relinquish control of their platforms and weapons material without 
weapons engagement. Active sonar prosecution is authorized to ensure new Red Force 
subsurface targets are fiilly aware of Blue Force presence. USWC objective is to drive 
Red Force targets south of Straits towards uninhabited coastline. 


Day 26-30 ; (Mini-Submarine Identification and Weapons Engagement) 

Event 1: (CVN to Coalition CVN) USWC conducts coordinated prosecution planning 
activities with Indian Naval Force counterparts to detect, locate and engage new Red 
Force mini-submarines at the earliest opportunity. 


Event 2: (CVN to all Coalition and TG-ASW forces using audio and digital data) - All 
air, sea, and submarine forces conducting R&S duties to detect and locate new Red Force 
targets. 


Event 3: (Ships to CVN; Aircraft to CVN; and SURTASS to Overseas Shore to CVN 
using audio, video, graphic digital data) Surface, aircraft, and SURTASS R&S 
operations confirm detection and location of two HPSB and two mini-submarines nearing 
Straits of Malacca. 
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Event 4: (CVN Secure Broadcast to TG-ASW and Coalition Force) USWC orders 
surface, submarine and air weapons carrying platforms to ready for shallow water 
engagement of mini-submarine. 


Event 5: (Aircraft to Surface Ship to CVN using audio and digital data) Forward SH-60 
aircraft report visual surface contacts to TG-ASW awaiting orders. 


Event 6: (CVN to United States Shore headquarters using audio, video, digital data) TG- 
ASW Commander live feed report to PACOM, NCA, and POTUS current status of mini¬ 
submarines. 


Event 7: (CVN to SH-60 using audio, digital data) USWC orders SH-60 aircraft to 
communicate directly with Red Force mini-submarines of Blue Force intent to engage 
and sink if necessary. 


Event 8: (Visual signals from enemy to aircraft) Red Force mini-submarines wave white 
flag, and makes voice communications that they are ready to turnover cargo and vessels 
to boarding crews. 


Event 9: (Coordinated communications between Blue and Coalition Forces using audio, 
digital data) On scene Blue Force coalition assets coordinate boarding event by Indian 
Navy crews to ensure cargo is retrieved for Indian government. 


Event 10: Mission complete. 


DETECTION EVENT LOG 

The Detection Event Log was created at the request of this capstone project’s 
modeling and simulation team to improve their understanding of specific operational 
scenario sensing and communication events. Fictitious events were itemized to paint a 
picture of probable occurrences during the course of an at sea exercise or real world 
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event. This log served to baseline inputs used in the modeling of the FY2020 Joint ASW 
C4I Architecture. 

The section provides the underpinning of this capstone project design team’s 
modeling and simulation initiatives by identifying specific “contact made” input 
parameter information derived from detection events occurring in this fictitious 
operational scenario. Figure 89 provides a geographical depiction of the expected 
operating area once the Blue Force commences its reconnaissance and surveillance 
missions by sea, air, and space. 
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Figure 89. Data Quadrant Identifiers 

This chart depicts quadrant identifiers to offer positional awareness of individual platforms 
specified in the event log. With the center point at 10 degrees north by 80 degrees east the 
quadrant positions are as follows: Quadrant I (southwest), Quadrant II (southeast), Quadrant III 
(northeast), and Quadrant IV (northwest) [Comprehensive Swath Bathymetric Survey of entire 
Indian EEZ, 2008]. 


The Blue Foree Detection Event Log represents the single database consolidating 
contact information received from each of the naval platforms. It keeps a eomplete 
reeord of Blue Foree eontacts as communicated by all available sensing modes. Excerpts 
of this log are provided below to baseline the data reeeived over the eourse of the 
scenario. The log presents information by day, the position quadrant of the deteetion, the 
operational reporting node that deteeted the contact, the time of detection, type of sensor 
making the detection, data type, the target deteeted, and the fusion bin receiving the 
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information. Reporting nodes include all data sources impacting the operational 
environment including CNN broadcasts; specific Blue Force surface ships, submarines, 
and aircraft, as well as, coalition force platforms. Time of detection will be in military 
time (Zulu) to ensure all commanders and operational units are using the same clock. 
Contacts will be surface ships and submarines but include anomalies and unknowns. 
Type of data is primarily identified as digital although reference is made to audio, video, 
and voice. Targets detected are classified when identified as Merchant Ship, Red 
Platform (X), and others. Fusion bins have been limited to surface, sub, intelligence and 
all to permit more focused modeling initiatives. The details of the Blue Force Detection 
Event Log can be found in Figure 90 through Figure 93. 
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Blue Force I>etection Event Log 

Day 

PosMioM 

Repoit^^ 

Node 

Defect 

Ttae(:Q 

Bke Fowe 

Seesor 

Data 

Type 

Target 

Fteina 

Bia 

Phase I: InitiaL Preparaticai of the Battlespaee 
(Command & Control) 

1 

IV 

SAT 

060000 

Cam^a 

Image 

Unk Sk: Cortacts 

kitel 

1 

IV 

CNN 

0600:15 

Human 

AudA^id 

kidia HaitxirAiea 

kitel 

1 

IV 

SURTASS 

060030 

Towed Arr^ 

Digital 

Unk Sub on Sk: 

Surtee 

1 

IV 

NOPF 

060500 

Relay 

Digital 

Unk Sub on Sk: 

Surtee 

1 

IV 

PACOM 

070000 

Human. 

SeeVTC 

Blue TF Ass^nmert 

All 

1 

IV 

P-3D 

07f2000 

ISAR 

Digital 

Unk Sfc Contact 

Surtee 

1 

IV 

E2 

07f23f20 

ISAR 

Digital 

Unk Sfc Contact 

Surtee 

1 

IV 

P-3D 

07f2500 

Visual 

Voice 

Ur^c MkilBub 

Surtee 

1 

IV 

CGN 

07f2500 

Bow Sonar 

Digital 

Unk Siti Cortact 

Sub 

1 

IV 

CGN 

07f2530 

Bow Sonar 

Digital 

Unk Siti Cortact 

Sub 

1 

IV 

P-3D 

07f25:45 

Sonohuoy 

Digital 

MkiiSiti-RI 

Sub 

1 

IV 

CGN 

07f2600 

Bow Sonar 

Digital 

MkiiSiti-RI 

Sub 

1 

IV 

P-3D 

07f2730 

Sonohuoy 

Digital 

MkiiSiti-RI 

Sub 

1 

IV 

SH-60 

07f29:45 

Dpped Anay 

Digital 

MkiiSiti-RI 

Sub 

1 

IV 

7fti Fleet 

073000 

Human 

SeeVTC 

TGASW Assorted 

All 

1 

IV 

SH-60 

073900 

Dpped Anay 

Digital 

MkiiSiti-RI 

Sub 

1 

IV 

SH-60 

07:4000 

Sonohuoy 

Digital 

MkiiSiti-RI 

Sub 

1 

IV 

CGN 

073500 

Cost Contact in ^oise of Littoraf. 

Last Posit 

1 

IV 

SH-60 

07:4500 

Lost SlJ^B Contact inS^oise of Littoraf. 

Last Posit 

5Vb (Furtfier Entries {Da/y. 

2 

IV 

RC-135 

020000 

ESM 

Digital 

Meichart Sh|i 

Surtee 

2 

II 

P-3D 

020500 

ISAR 

Digital 

Meichart Sh|i 

Surtee 

2 

IV 

SURTASS 

023000 

Towed Arr^ 

Digital 

Meichart Sh|i 

Surtee 

2 

IV 

CGN 

02:1000 

Bow Sonar 

Digital 

Meichart Sh|i 

Surtee 

2 

II 

P-3D 

02:1500 

Sonohuoy 

Digital 

Meichart Sh|i 

Surtee 

2 

II 

SAT 

023000 

Cam^a 

Video 

kidia HaiborAiea 

kitel 

2 

IV 

FFG 

02f2000 

ESM 

Digital 

Meichart Sh|} 

Surtee 

2 

II 

F/A-18 

02f2500 

Visual 

Digital 

Meichart Sh|} 

Surtee 

'^astSound^Suffiice Contacts Out - 03:1S:00. 

^Q-^SW ^nroute ^ay of <3cn^af Operations. 

5Vb 'Fm rtker Entries ^Ris Q}ay. 


Figure 90. Blue Force Detection Event Log (Day 1-2) 

This table provides two specifie days of Phase I events detailing the Initial Preparation of the 
Battlespaee (Command and Control) portion of the operational scenario. 
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Blue Force I>etection Event Log 

Day 

FnsMlDn 

Repoiti^ 

Node 

Detect 

Bke Foice 

Sensor 

Data 

Type 

Target 

Fksmn 

Bh 

Phase II: Extended Reconnaissance and Snrvemance 
(Conduct R&S; Develops Maintain Common Operational Picture) 

3 

IV 

PACOMJ2 

130000 

AH Source 

Digital 

Himan Analysis 

All 

3 

IV 

CGN 

140000 

Bow Sonar 

Digital 

Meichart Sh|i 

Surtee 

3 

II 

E2 

140500 

ESM 

Digital 

Meichart Sh|i 

Surtee 

3 

IV 

SSN 

14:1000 

Bow Sonar 

Digital 

Meichart Sh|i 

Surtee 

3 

II 

EP-3 

14:1500 

ISAR 

Digital 

Meichart Sh|i 

Surtee 

3 

II 

SAT 

14:1800 

Camera. 

Image 

Meichart Sh|i 

htel 

3 

IV 

CVN 

14f2000 

RADAR 

Digital 

Meichart Sh|i 

Surtee 

3 

II 

SSN 

14f22O0 

ESM 

Digital 

Meichart Sh|i 

Surtee 

3 

II 

RC-135 

14f25O0 

ISAR 

Digital 

Meichart Sh|i 

Surtee 

3 

IV 

PACOMJ2 

160000 

AH Source 

Digital 

Himan Analysis 

All 

3 

IV 

NOPF 

183000 

Relay 

Digital 

Meichart Sh|is 

Surtee 

3 

IV 

PACOMJ2 

160000 

AH Source 

Digital 

Himan Analysis 

All 

3 

II 

SSN 

19f22O0 

Visual 

Digital 

Meichart Sh|i 

Surtee 

%i/estSoun£f Commerciaf Surface Contacts Out qf^ai^e - 19:IS:00. 

Conducting ^ay of ^enjjaf Operations. 

^urtker Entries ^kis (Dav. 

7 

II 

SSN 

02f2200 

ESM 

Digital 

Meichart Sh|i 

Surtee 

7 

IV 

PACOMJ2 

040000 

AH Source 

Digital 

Himan Analysis 

All 

7 

II 

CGN 

070000 

Bow Sonar 

Digital 

Meichart Sh|i 

Surtee 

7 

IV 

PACOMJ2 

070000 

AH Source 

Digital 

Himan Analysis 

All 

7 

IV 

EP-3 

070500 

ISAR 

Digital 

Meichart Sh|i 

Surtee 

7 

IV 

FFG 

07:1030 

ESM 

Digital 

Meichart Sh|i 

Surtee 

7 

II 

P-3D 

07:1030 

Sonobuoy 

Digital 

Meichart Sh|i 

Surtee 

7 

II 

SAT 

07:1500 

Camera 

Video 

kidia HaitxirAiea 

htel 

7 

II 

CGN 

07f2000 

Bow Sonar 

Digital 

Meichart Sh|i 

Surtee 

7 

II 

SSN 

07f2200 

Bow Sonar 

Digital 

Meichart Sh|i 

Surtee 

7 

II 

EP-3 

07f2500 

ISAR 

Digital 

Meichart Sh|i 

Surtee 

7 

II 

CGN 

073000 

Bow Sonar 

Digital 

Whale 

Sub 

7 

II 

FFG 

080000 

ESM 

Digital 

Meichart Sh|i 

Surtee 

7 

IV 

EP-3 

080500 

ISAR 

Digital 

Meichart Sh|i 

Surtee 

7 

IV 

CGN 

08:1030 

ESM 

Digital 

Meichart Sh|i 

Surtee 

7 

II 

SH-60 

08:1030 

Sonobuoy 

Digital 

Urtc Siti 

Sub 

7 

II 

SAT 

08:1500 

Camera 

Video 

kidia HaitxirAiea 

htel 

7 

II 

FFG 

08fZ0O0 

Bow Sonar 

Digital 

Whale 

Sub 

7 

II 

SH-60 

08f2500 

Visual 

Digital 

Whale 

Surtee 

7 

IV 

PACOMJ2 

lOOOOO 

AH Source 

Digital 

Himan Analysis 

All 

7 

II 

CGN 

183000 

Bow Sonar 

Digital 

Meichart Sh|i 

Surtee 

^aintaitied ^ast ^^est&ound CommerdatSurface Contacts *F,x>'ery 15 Minutes. 

J^o ^uftker Entries ^kis (Day. 


Figure 91. Blue Force Detection Event Log (Day 3-7) 

This table provides two specific days of Phase II events detailing the Extended Reconnaissance 
and Surveillance (Conduct Reconnaissance and Surveillance; Develop and Maintain Common 
Operational Picture) portion of the operational scenario. 
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Blue Force I>etection Event Log 

Day 

FosMIdm 

Repoit^^ 

Node 

Detect 

Bke Foice 

SeKor 

Data 

Type 

Target 

fksioa 

Bh 

Phase ill: Proactive Prosecution 
(Red Force Detection & Prosecution) 

20 

IV 

PACOM J2 

19i)0i)0 

AH Source 

Digital 

Human Analysis 

All 

20 

11 

SSN 

20f26i)0 

Deployed 

Digital 

Red Sub {Kio) 

Surtee 

20 

11 

RC-8C 

2030i)5 

ESM 

Digital 

Red Sub {Kio) 

Surtee 

20 

IV 

RC-8C 

20:45i)0 

ESM 

Digital 

RedCVN 

Surtee 

20 

11 

SSN 

2050i)0 

Bow Sonar 

Digital 

RedCVN 

Surtee 

20 

11 

EP-3 

2DOOi)0 

ISAR 

Digital 

RedCVN 

Surtee 

20 

IV 

CGN 

21f20:15 

ESM 

Digital 

RedCVN 

Surtee 

20 

IV 

PACOM J2 

22i)0i)0 

AH Source 

Digital 

Human Analysis 

All 

20 

11 

EP-3 

22:10i)5 

ISAR 

Digital 

Red Sub {Kilo) Mast 

Surtee 

20 

11 

SSN 

23f22i)0 

Bow Sonar 

Digital 

Red Sub {Kio) 

Sub 

20 

IV 

CGN 

23f25f28 

ESM 

Digital 

RedCVN 

Surtee 

20 

11 

P-3D 

2330i)0 

Sonobuoy 

Digital 

Red Sub {Kio) 

Sub 

20 

IV 

CGN 

23:45i)0 

ESM 

Digital 

RedCVN 

Surtee 

20 

IV 

P-3D 

2350i)0 

Sonobuoy 

Digital 

Red Sub {Kio) 

Sub 

20 

IV 

CGN 

2355:10 

ESM 

Digital 

RedCVN 

Surtee 

20 

11 

SSN 

2358i)0 

Bow Sonar 

Digital 

Red Sub {Kio) 

Sub 

!Mixintain ‘witfi India %ito C^ass SuSmatine ^Jiircr^t 

iHo ^uftket ^ntftBS ^kis <Day. 


25 

IV 

PACOM J2 

22i)0i)0 

AH Source 

Digital 

Human Analysis 

All 

25 

IV 

CGN 

2355:10 

ESM 

Digital 

RedCVN 

Surtee 

25 

11 

SSN 

2358i)0 

Bow Sonar 

Digital 

Red Sub {Kio) 

Sub 

^yitected to Coordinate Operations ^itk India's OnScetie Sda^v at Commander 

3do furthe r Entries ^kis CDay. 


Figure 92. Blue Force Detection Event Log (Day 20 - 25) 

This table provides two specific days of Phase III events detailing the proactive prosecution (Red 
Force Detection and Prosecution) portion of the operational scenario. 
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Blue Force l>e4ec4ion Event Log 

Day 

PosiliDM 

Qfeadrut 

Repoitiag 

Node 

Detect 

13.em 

Blae Foire 

Seasw 

Data 

Type 

Tar^get 

FasioM 

Bin 

Phase IV : Command Controlled Weapons Engagement 
(Mmi-Suhiiiarlne Identification and Weapons Engagement) 

26 

IV 

T&-ASW 

oimm 

Btoadcast 

D^g^tal 

Cbaftion Cbmms 

All 

26 

IV 

PACOMI2 

oimm 

AlSoiroe 

D^g^tal 

Human Analysis 

All 

26 

IV 

CoafixmlF 

01-30i)0 

Btoadcast 

D^g^tal 

Search Locdhon 

All 

26 

IV 

RC-8C 

05z45i)0 

ESM 

D^g^tal 

Search Aiea Acthity 

Suifece 

26 

IV 

PACOMI2 


AlSoiroe 

D^g^tal 

Human Analysis 

All 

26 

IV 

F/A-IS 

04:1 OtX) 

RADAR 

D^g^tal 

Hi^ Speed Boats 

Suifece 

26 

IV 

F/A-IS 

04:15i)0 

Vsnal 

D^g^tal 

HSBs ¥(/Mini Subs 

Suifece 

26 

IV 

P-3D 

05i)5t)0 

ISAR 

D^g^tal 

HSBs ¥(/Mini Subs 

Suifece 

26 

IV 

P-3D 

05-35i)0 

ISAR 

D^g^tal 

HSBs Undenvay 

Suifece 

26 

IV 

P-3D 

05zAOi)0 

ISAR 

D^g^tal 

Mini-Subs Dning 

Sub 

26 

IV 

P-3D 

05z45i)0 

SooobiKiy 

D^g^tal 

Red M ni-Subs 

Sub 

26 

IV 

P-3D 

OTiMiX) 

SooobiKiy 

D^g^tal 

Red M ni-Subs 

Sub 

ConiiUTt SuB marines S^^eed ^oats. 

3fo ^urtBer Entries Tifis CDoy. 


IV 

CoaitinaHeL 

15*505 

Dppa^ Array 

D^g^tal 

Mira Sii>s (R1 & R2) 

Sub 

29 

IV 

PACOMI2 

160000 

AlSoiroe 

D^g^tal 

Human Analysis 

All 

29 

IV 

P-3D 

160500 

ISAR 

D^g^tal 

HSBs 

Suifece 

29 

IV 

StL60 

17^2500 

Dppa^ Array 

D^g^tal 

Mira-Sii>s (R1 & R2) 

Sub 

29 

IV 

CGN 

1S50O0 

ESM 

D^g^tal 

HSB Sisals 

Suifece 

29 

IV 

P-3D 

1S55O0 

ISAR 

D^g^tal 

R1 & R2 on Sratace 

All 

29 

IV 

PACOMI2 

190000 

AlSoiroe 

D^g^tal 

Human Analysis 

All 

29 

IV 

CoaiIxmSSN 

190500 

RADAR 

D^g^tal 

R1 & R2 on Sratace 

All 

29 

IV 

StL60 

19J5O0 

Vsnal 

D^g^tal 

R1 & R2 on Sratace 

All 

29 

IV 

FFG 

200000 

We^Km 

D^g^tal 

Lock on R1 

All 

29 

IV 

CoaiIxmSSN 

200500 

We^Km 

D^g^tal 

Lock on R2 

All 

29 

IV 

F/A-IS 

210000 

We^Km 

D^g^tal 

Lock on HSB 1 

All 

29 

IV 

P-3D 

215000 

We^Km 

D^g^tal 

Lock on HSB 2 

All 

29 

IV 

SAT 

215500 

Camera 

Video 

Aiea Owniew 

Intel 

^Maintain %i/eapons iMini SuBmarines Speed <Soats. 

CoaCitinn 2^as^^orce ^(pd Worce, 

30 

IV 

CoaiIxmSSN 

002400 

Vsnal 

D^g^tal 

Mini Sub (R1) 

All 

30 

IV 

FFG 

005000 

Vsnal 

D^g^tal 

Mini Sub (R2) 

All 

30 

IV 

CGN 

005200 

Vsnal 

D^g^tal 

HSB 1 

All 

30 

IV 

SSN 

005600 

Vsnal 

D^g^tal 

HSB 2 

All 

30 

IV 

SSNNSW 

OlOOOO 

Vsnal 

D^g^tal 

NSW Borads HSB 2 

All 

30 

IV 

SSN NSW 

01:1500 

Vsnal 

D^g^tal 

HSB 2 Safe 

All 

30 

IV 

CGN Boat 

020000 

Vsnal 

D^g^tal 

HSB 1 Safe 

All 

30 

IV 

CoaiIxmSSN 

030050 

Torpedo 

D^g^tal 

Mini-Sub R1 Sraik 

All 

30 

IV 

FFG Boat 

040000 

Vsnal 

D^g^tal 

Clew Boanls R2 

All 

30 

IV 

FFG 

040052 

We^Kxn 

D^g^tal 

Lock on R2 

All 

30 

IV 

FFG Boat 

042000 

We^Kxn 

D^g^tal 

Mira-Sii> R2Safe 

All 

Qoa£i±ix^n ^Ihs^^orce Commander ^S^^orts Jiii ^SSpd forces or Sun^ 

!NucCear ^Materiaf ^(pcCaimed and ^Sptumed to India ^a%>af Commander; 

^ini-SuB ^2 Zhider By ^die ^orce ^F^FQ. ^Mission Complete. 

!Ub Fu rtBer ^ntri^s ^PBis CDay. 


Figure 93. Blue Force Detection Event Log (Day 26 - 30) 

This table provides three specific days of Phase IV events detailing the Command Controlled 
Weapons Engagement (Mini-Submarine Identification and Weapons Engagement) portion of the 
operational scenario. 


264 












































































APPENDIX I. MODELING AND SIMULATION RESULTS 


The tool utilized for modeling and simulation of each alternative was EXTEND, 
from which the results were extracted. Each alternative was simulated ten times with 
EXTEND to obtain sufficient data for each measurement. The data gathered for each 
simulation run represented numerous track reports that existed in the scenario 
environment. For data reduction, the data was then reduced to construct histograms that 
allowed for a graphical view of the ranges where the frequency of the measurements was 
greater, which were then used to compare against the overall average of the 
measurements. Figure 94 to Figure 102 show these histograms. 

In the figures below, the measurements provided in the results represented 
throughput, latency, and data fusion time measurements. The data obtained from the 
EXTEND model was extracted similarly for all the evaluation measures. Throughput 
data was achieved by placing nodes at the output of contact tracks and after the capacity 
and physical delays. This allowed for a consistent measurement of how much data was 
able to travel through the nodes and at what rate. Next, the latency measurement was 
obtained by allocating timers at particular locations in the model which would obtain the 
time when a track entered the control section and when it exited the section. This 
configuration provided a measurement of time duration of contact tracks when as they 
traveled from input to output. The measurement for data fusion processing was obtained 
by incorporating a timer within the black box after all the inputs such as sensor, METOC, 
and user data were fused and sent to the COTP. Table 26 shows the overall results for 
each of the alternatives. 


Measurement 

AitO 

Aiti 

Ait 2 

Aits 

Data Fusion Processing Time (ms) 

702.395 

540.139 

299.823 

299.720 

Latency (ms) 

1334.161 

1205.027 

685.560 

680.160 

Throughput (kbps) 

51.292 

53.930 

58.855 

58.155 


Table 26. Modeling and Simulation Results 

This table shows the M&S results for each alternative. It demonstrates the averages of all the ten 
runs for all of the alternatives. It can be observed from the table that Alternative 2 had the greatest 
throughput and Alternative 3 had the lowest latency value and lowest data fusion processing time. 
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Figure 94. The Histogram for Data Fusion of Alternative 0 

This figure shows the histogram of the fusion time measurement for Alternative 0. It is a 
culmination of all the data points obtained from ten consecutive simulations that modeled 
Alternative 1 in the scenario environment. 
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Figure 95. The Histogram for Data Fusion of Alternative 2 

This figure shows the histogram of the fusion time measurement for Alternative 2. It is a 
culmination of all the data points obtained from ten consecutive simulations that modeled 
Alternative 2 in the scenario environment. 
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Data Fusion Alt3 



Data Fusion Time (ms) 


Figure 96. The Histogram for Data Fusion of Alternative 3 

This figure shows the histogram of the fusion time measurement for Alternative 3. It is a 
culmination of all the data points obtained from ten consecutive simulations that modeled 
Alternative 3 in the scenario environment. 



Figure 97. The Histogram for Latency of Alternative 0 

After obtaining the raw data from EXTEND model, appropriate histogram bins were created to 
show the overall data distribution. This figure shows the data distribution for Latency 
measurement for Alternative 0. Histogram of Latency for Alternative 0 shows the bimodal nature 
distribution. 
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Latency Alt1 



Latency Time (ms) 


Figure 98. The Histogram for Latency of Alternative 1 

After obtaining the raw data from EXTEND model, appropriate histogram bins were created to 
show the overall data distribution. This figure shows the data distribution for Latency 
measurement for Alternative 1. Histogram of Latency for Alternative 1 shows the normal curve 
distribution. 


Latency Alt2 



Latency Time (ms) 


Figure 99. The Histogram for Latency of Alternative 2 

After obtaining the raw data from EXTEND model, appropriate histogram bins were created to show 
the overall data distribution. This figure shows the data distribution for Latency measurement for 
Alternative 2. Histogram of Latency for Alternative 2 shows the normal curve distribution. 
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Throughput Alt1 
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Figure 100. The Histogram for Throughput of Alternative 1 

This figure shows the histogram of the throughput measurement for Alternative 1. It is a 
culmination of all the data points obtained from ten consecutive simulations that modeled 
Alternative 1 in the scenario environment. 
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Figure 101. The Histogram for Throughput of Alternative 2 

This figure shows the histogram of the throughput measurement for Alternative 2. It is a 
culmination of all the data points obtained from ten consecutive simulations that modeled 
Alternative 2 in the scenario environment. 
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Throughput Alt3 



Figure 102. The Histogram for Throughput of Alternative 3 

This figure shows the histogram of the throughput measurement for Alternative 3. It is a 
culmination of all the data points obtained from ten consecutive simulations that modeled 
Alternative 3 in the scenario environment. 
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